July 19, 2014 By: eagleeyetom
Software is never completely secure. If you think otherwise, you are in for a rude awakening. Every now and then, hackers will find a way to take control of an app or expose private data–for money, fun, or fame. Motives varies, but these types of hackers are extremely talented, and often their potential is wasted to illegal activities. One of good guys in finding and neutralizing security flaws is Google. Current efforts have been focused mainly on their own products like Chrome OS or Chrome browser. But now, the whole idea of protecting the Internet has gone to a new level.
The Android Open Source Project is a good example of how the community can be used to make a big project used by millions safer and more complete. Android isn’t made only by developers gathered together in Mountain View. We’ve seen some contributions made by multiple XDA developers like Senior Recognized Developers jcase and Chainfire. Google obviously found out that some talented hackers are spread all over the world, so they came up with a new initiative, Google Project Zero. It’s a team made of top Google security researchers that have a sole mission to keep the world safe–free of security flaws, like the Heartbleed bug in OpenSSL project. Google Project Zero’s mission is to try and expose every security vulnerability and let companies know to fix them.
Google has already recruited some hackers from their own company and even XDA. New Zealander Ben Hawkes discovered dozens of bugs in software like Adobe Flash or Microsoft Office 2013. English researcher Tavis Ormandy discovered some zero-day vulnerabilities in antivirus software. Finally, George Hotz, for us known more as XDA Recognized Developer GeoHot, the creator of the Towelroot root exploit compatible with almost every device using an unpatched kernel. Before creating Towelroot, GeoHot was involved in iOS Jailbreaking and won the Pwnium hacking competition last March. Last but not least is Ian Beer. With such an All-Star team, Internet users will one day be a bit more safe.
It’s remain unanswered whether Google Project Zero will be a successful initiative. That said, exposing the flaws in order to encourage and allow companies to fix them is an innovative project, and other companies should follow the Google’s path in making the Web a safer place to work, communicate, and simply have fun.
July 18, 2014 By: Jimmy McGee
We’ve already reported on two of the speakers scheduled for XDA:DevCon 2014. Sony’s Alin Jerpelea and Mozilla’s Alex Lakatos are joining us, as we go international with xda:devcon ’14. If you haven’t heard, it will be held in Manchester, UK on the weekend of September 26-28.
Today, we are happy to announce another great speaker that will be at xda:devcon ’14. With many different governments spying on you, Android security is a big topic. So to cover the important information of Android security, full-time master student engineering at the department of Computer Science at the KU Leuven University Dario Incalza will be presenting. Incalza has been involved with Android development for four years and passionate about security since the age of 13-14. He has been combining both of these over the last few years. His studies have him majoring in the development of secure software with a master thesis focusing on the security of web-based Android applications.
At xda:devcon ’13, XDA Elite Recognized Developer jcase gave a presentation entitled “Android Security Vulnerabilities and Exploits.” In his presentation, Jcase talked about how the very exploits we often use to root our phones expose us and others to malicious software such as spyware, bots, keyloggers, and other forms of malware.
This year, Incalza offers up another excellent presentation talking about the Android Security with a presentation entitled, “Android Security Overview and Safe Practices for Web-Based Android Applications.” The talks will give you a brief overview of the different layers of the Android platform, with a focus on the parts attackers find interesting. Next, the presentation will talk about the several attack surfaces for Android, like remote, physical and more. Finally, the presentation will segue into Web-based apps, as Web applications have different security implications. This talk aims to give developers the information and motivations to take better care of security when developing.
June 25, 2014 By: Pulser_G2
With the announcement of Android L now finished at Google I/O, there are still a number of unanswered questions as to what’s actually likely to be coming in Android L. We mentioned some of the changes we know are coming earlier, as well as a bit more about the new design philosophy on the way, but there wasn’t much detail given over some of the new changes.
We’ve been taking a look to see what we could find, and XDA Senior Recognized Developer XpLoDWilD helped us root out what looks to be an interesting new feature–tucked away among all the other information about Android L and the new design philosophy are a few interesting gems. One of these gems comes in the form of a screenshot, which appears to suggest that the Android permissions system will be introducing some “at-time-of-use” prompts, somewhat like iOS.
As shown in the image above, it appears that the Permissions UI is extending to cover a prompt issued at time of use, allowing the user to allow or deny the location information. While these don’t, at a glance, appear hugely different to the existing prompts to enable Location Services, we suspect these are different and tie into the new Unified Data Controls discussed in the keynote. The wording indicates this permission prompt affects only the one app, which would appear to indicate that there will be some iOS permissions prompts when apps seek to access sensitive data, or use features which require permissions.
This would certainly be an interesting step forwards, as it would raise user awareness of what apps have access to, and also give users an option to disable an app’s access to the permission, if they feel it is excessive. We’ll know for sure tomorrow though, when the Android L developer preview lands.
June 16, 2014 By: Will Verduzco
If you’ve ever tried to modify and reinstall a system application, you probably encountered application signature checks in one form or another. Either you removed the original app before proceeding, or you gave your modified APK another package name in order to get it to install without first removing the old application. And in either case, you also had to re-sign the application yourself in order to get it to install in the first place.
You can get around all of these behaviors by temporarily disabling application signature checks. But before we get into the metaphorical meat and potatoes of this article and tell you how to do so, it’s critical that we talk a little bit about application signature checks, what they do, and why you should never remove them in the vast majority of cases. READ ON »
June 11, 2014 By: Pulser_G2
After yesterday’s article about Google’s recent changes to the Play Store that post a number of privacy concerns for users, today we are going to look at the three most popular options for users to protect their own privacy on their Android devices. First though, let’s take a look at how they work, and what they are for.
Since the start, Android has had a permissions system, to allow users to control what apps are able to do on their device. When an application is installed, the user is prompted to agree to the permissions that an app requires. The Android operating system ensures apps cannot use permissions they have not requested, and the user is responsible for deciding if an app can be installed.
At first this worked well, as users could see what data an app could access. Unfortunately, however, developers found that very few users paid much attention to the permissions prompts, and it became more common for developers to use more and more permissions–presumably to either improve user experience or monetize their apps.
In light of this, today we have reached a point where a front-page featured game from the Play Store makes use of the following permissions:
All this for a game that lets you play some fantasy football? At this point, I must open up a few questions to the reader (feel free to discuss in the comments below): Is there any possible justification for about half of these permissions? Is it necessary for this app to see what other apps a user is using? Or to see what accounts the user has on his/her device? Or to access your exact location in the world using GPS? Or to read your IMEI number, and the phone number of someone you are on a phone call with?
This is not an isolated incident. It is just the first app I selected on the front page of the Play Store. Select another, and have a look for yourself! Because of the fact that the vast majority of apps are now making use of what I argue to be excessive permissions, a growing number of users feel it’s no longer enough to simply not use applications that use excessive permissions. That gives rise to a common request, which is for users to select which permissions an app can access. This returns the balance of power towards the user, whose phone is running the app, rather than the developer, who was previously free to dictate the permissions their app required to run.
The obvious solution for the tech community is to develop ways to have greater control over what apps are able to do, and to prevent them from using all of the permissions which they request. The three most common ways to revoke permissions are App Ops, Privacy Guard, and XPrivacy.
The first way to get more control over your device is via a feature known as “App Ops.” This was originally introduced by Google in Android 4.3 as a hidden feature. With the release of KitKat, Google made it more difficult to access App Ops, but continued to introduce new improvements to the feature. Ultimately in Android 4.4.2, Google removed access to App Ops. However, it’s still possible to access with root and an Xposed modification or custom ROM.
The main limitation of App Ops is that, being made by Google, it only lets you block access to things that they are willing to let you block. Notably, App Ops doesn’t provide any ability to control whether an application should have access to the Internet. It’s also not possible to prevent apps from uniquely identifying your device, or you as a user, via your third party accounts. This means that an app can still tie together all of your account identities on your device and access your IMEI and other unique device identifiers with the appropriate permissions, and it’s not possible to prevent this using App Ops.
A cynic could argue that Google has a serious ulterior motive to prevent users from blocking apps from accessing the Internet. After all, Google has incentive to push their in-app advertising and gather information about users for Google Analytics. Likewise, Google is proficient at creating a profile of its users, which would explain why it’s not possible to block your identity from applications via your account names. The ability to access unique device identifiers only helps to allow other applications to track your usage (and thus allow Google to track your usage across applications).
For this reason, we believe that while App Ops is a lot better than nothing (you can control access to your contacts, messages, location, and so on), it is definitely not the best solution for protecting your privacy. There are a number of types of data that cannot be blocked, and it appears these may be related to Google’s motives in tracking and gathering data on its users. As such, we recommend you look at alternatives.
Privacy Guard is a feature originally developed by CyanogenMod to place a simple user interface over App Ops with a single “on/ off” toggle to control it. As such, Privacy Guard is subject to the same criticisms as App Ops in its limitations. It also imposes a notification at all times while running an application protected by Privacy Guard, supposedly to remind users that it is in operation.
Unfortunately, however, Privacy Guard makes no attempt to anonymize users or prevent apps from tracking their sessions via device identifiers or Internet access. With a single on-off control however, it’s certainly easy to use for beginners, and the default settings should be fairly good. The only downside is the lack of granularity, meaning that an app needing access to your location cannot be allowed that, while still blocking contacts and calendar access. Nonetheless, as a one-click solution, it works nicely. It does require the user to install a custom firmware though, which spoils the benefits of one-click appeal.
XPrivacy is the Swiss Army Knife of Android privacy protection. Compared to the other solutions we’ve looked at here, XPrivacy is much more customizable, but also much more complicated as a result. If you’re unfamiliar with Android permissions, XPrivacy is probably not the best place to start. It requires the Xposed framework, which means you also need a rooted device. However, XPrivacy should work on almost any ROM.
The main advantage of XPrivacy over alternatives is the sheer breadth and granularity of restrictions you can impose on apps. You can restrict an app to only be able to access and see certain accounts on your device, block access to your clipboard (to stop an app from accessing copied data), and even block access to the Internet, both directly, and via the web browser (to prevent any means of covert data exfiltration from your device). If there’s something you want to restrict, it’s almost guaranteed XPrivacy can restrict it.
Despite being a very powerful tool, there’s a large learning curve behind XPrivacy. I’d suggest reading through all the documentation on XDA Recognized Developer m66b’s Github repository (did I mention it’s fully open source?), and his thread on the XDA forums, for more information.
Overall, if you want absolute control over your private data, I’d recommend you check out XPrivacy. It takes a lot of getting used to, but it gives you unparalleled choice. If you are not quite as certain about what you’re doing, using App Ops will give you good control, albeit without the ability to control Internet access and data that identifies you as the user of the device. Both App Ops and XPrivacy are available on any ROM, via Xposed plugins. Privacy Guard is good for someone who simply wants a one-click solution, but the need to install a custom ROM to achieve it is a limitation in this regard, as you cannot (currently) find an implementation on stock firmwares.
A good developer is always concerned about the security of his/her users. Revealing your app’s private data to the public is generally a bad thing, and should almost always be avoided. As such, there are various ways to strengthen your app’s privacy, and every new method should be evaluated. Privacy protection is especially important with Android applications, as there are frequent reports of app-related phishing and similar shady activities.
You application’s private data can now be stored a bit safer, thanks to XDA Forum Moderator Jonny. He provides a Java class that protects your app’s data using the SHA-512 hashing algorithm to convert a string into a raw bit format. After that, it’s converted into hex strings. In plain English, the data sent to the application will be quite safe. The class provided by Jonny also adds a salt to the hash function, which makes your users’ private data even more secure.
If you are developing apps that use sensitive data such as logins, passwords, and other personal information, make your way to the original thread and consider enhancing the security of your project with this class.
Smartphones are undoubtedly the most “personal” of our personal computers. We use them to access our Email, banking information, and pretty much the rest of our private data. Luckily, there are quite a few file locker applications available to help keep prying eyes away from our Gmail. However, things get a bit trickier if you’re looking to hide files that reside on your device’s storage.
Sure, you can easily encrypt your internal storage through Android’s security settings menu, but what about your external storage? And what about those who want to let others casually access their devices but don’t want their tech savvy friends viewing their naughty selfies? Luckily, XDA Senior Member Doplgangr offers up a great app to encrypt files of your choosing.
Secrecy, as its name implies, allows you to hide and encrypt various files of your choosing. These can be pictures, videos, or any other file type. And unlike many other available options, Secrecy actually encrypts the files in question, rather than simply storing them as raw data in a hidden location.
Now there is one caveat here, and it’s a big one. While this application states that every file is encrypted with AES256, it is not open source. Thus, you can never truly be sure how securely your files are being stored. But for the casual user simply looking to make certain files inaccessible when a device is mounted to a PC, Secrecy certainly does the trick.
If you’re looking for a simple and user-friendly way of hiding your files, head over to the application thread and give Secrecy a shot.
April 10, 2014 By: Will Verduzco
Back in October of last year, we talked in depth about malware on Android and the platform’s multiple layers of defense. One of the final pieces of puzzle is of course Android’s Verify Apps feature. And while only around 0.5% of applications end up triggering this security mechanism, it’s still a great safety net to have when dealing with closed source applications of untrusted origin.
The Verify Apps feature, which is available on devices running Android 2.3 Gingerbread or later, has traditionally scanned apps against known malware signatures as they are installed. Now, Google has expanded the functionality of Verify Apps with constant device monitoring. This means that in addition to messages while installing applications with known malicious signatures (left two screenshots), your device will constantly search its installed applications for malware (right two).
In practice, the new functionality shouldn’t have too great of an impact on end-user security. Google states that after receiving a warning, only 0.18% of users actually end up installing the potentially malicious application. But then again, the list of known malicious signatures is constantly expanding, so even users who diligently deny installation to flagged apps will benefit.
The update to Verify Apps will be rolling out to your device through Google Play Services shortly, if it hasn’t already. Have you ever fallen victim to malware on Android? Have you seen any of the warnings above? Let us know in the comments below!
[Source: Official Android Blog]
March 13, 2014 By: Will Verduzco
Earlier today, we talked about how the Replicant team found a potential backdoor in Samsung’s proprietary radio software. As demonstrated in a proof-of-concept attack, this allowed certain baseband code to gain access to a device’s storage under a specific set of circumstances. But upon closer inspection, this backdoor is most likely not as bad as it was initially made out to be.
A few hours after posting our previous article on the alleged backdoor, a highly respected security expert who wishes to remain anonymous approached us, stating that the way in which the proof-of-concept attack was framed by the Replicant team was a bit misleading. Essentially, it boils down to the POC requiring a modified firmware with with security features disabled. Thus, if a user is running an updated version of the official firmware, this attack will not work. To that end, the Replicant team even states in their write-up that SELinux would considerably restrict the potential files that the modem can access, such as those on the /sdcard partition.
Now, another highly trusted security researcher (XDA Recognized Developer djrbliss) has gone on record with Ars, stating that there’s “virtually no evidence” that this is indeed a true backdoor, although his reasons are a bit different. There is absolutely no indication at this time that the baseband file access can be controlled remotely. Rather, this is only a “possibility,” since the baseband software is proprietary. Instead, it’s far more likely that this was only ever intended to write radio diagnostic files to the /efs/root directory, as that is is the radio user’s home directory.
In summary, we shouldn’t rush to replace our Samsung phones just yet. There is absolutely no evidence to state that this can be controlled remotely. And even if it were possible, using SELinux, which is set to Enforcing in stock firmware, would restrict the radio user’s access.
February 16, 2014 By: Will Verduzco
Google has been on a roll with a few high profile acquisitions and sales in the past month. Not too long ago, we talked about how the company had acquired the smart thermostat and carbon monoxide detector manufacturer Nest for $3.2 billion, and how this could signal the coming of future home automation products from the Mountain View company. Then, we were all relatively surprised when we saw Lenovo take money pit Motorola from their hands for a cool $2.91 billion. Now, Google has gone ahead and acquired the SlickLogin team.
For the unaware, Israeli-based SlickLogin pioneered a unique authentication method designed to make traditional security measures a thing of the past. Rather than using traditional passwords or identifiable biometrics, SlickLogin’s method utilized ultrasonic sounds emitted from a user’s computer, which are then used to authenticate that the person trying to gain access is indeed you. Needless to say, this falls inline with Google’s continual push to encourage stronger passwords and two layer authentication.
The details surrounding the acquisition are unfortunately sparse at present, but we will update this article as soon as more information is known. Let us know your thoughts in the comments below!
Don’t you hate it when you are stuck in a crowd and you need to unlock your mobile device? Sure, the vast majority of the time, nobody’s genuinely trying to sneak a peek at your lock screen code—but you never truly know who’s watching. Because of the potential danger of having others learn our lock screen codes, we all try various “techniques” to thwart would-be prying eyes. But let’s face it—if somebody really wants to stealthily learn your lock screen code, there’s a good chance that they’ll find it.
Rather than using a single, predefined unlock code, wouldn’t it be nice if you could have a time-based PIN that changes so that a password that works one minute won’t work the next? And wouldn’t it be nice if this PIN relied on something like the time of day so that you could never accidentally forget? Well, that’s exactly what XDA Senior Recognized Developer jcase has done with his new application TimePIN.
TimePIN does exactly as its name states. It allows you to enter a 4-digit PIN based on the current time of day to unlock your device. And if somebody happens to sneak a peek at your unlock code, it won’t do them any good unless they somehow figure out that the PIN changes based on the time of day. Obviously for this to work, you must grant the application Device Administrator status. However, the process is painlessly easy, and you will be up and running in no time.
What about if you want to make things a bit more complicated for those would-be hackers? Never fear, as jcase has you covered. Through a series of modifiers, you can obfuscate the original time from the generated PIN code. For example, the if the time is 12:34 and you enable the “reverse” modifier, the code will become 4321. And for an even greater degree of security, there are also other modifiers available such as mirror (12344321), double (12341234), and offset (add a predefined offset to the PIN). What’s more, these additional modifiers can be stacked together for a seriously complicated password that only you could ever know.
TimePIN is available for free and comes with the time-based PIN functionality, as well as the reverse modifier. However, a small $1.99 in-app purchase unlocks all of the additional modifiers for life. Fend off those pesky password snoopers by heading over to the application thread to get started.
Those who’d rather see it action before jumping on the bandwagon should check out the demo video made by jcase himself below:
January 28, 2014 By: egzthunder1
Remember all those times when we here at the XDA Portal have told you that privacy is important? Despite many people thinking that we are all just a bunch of nerds wearing tinfoil hats, we do have our reasons to be somewhat paranoid. After all, we’re quite sure that you wouldn’t like the idea of having somebody snoop around your cell phone for all the naughty pictures and messages sent to and from your significant other. If you couldn’t care less about who reads the information on your device, then you might as well just go ahead and install Facebook. Yes, the Facebook app for Android. Yes, the free one from the Play Store. But, wait… Why would this app even be highlighted here? If this caught your attention, you will be glad to know that Facebook now has access to yet another part of your mobile life: your SMS and MMS messages.
Those of you in the US (and many abroad who are avidly for organically grown food) will likely remember an episode last year when the Monsanto Bill was passed along with a massive binder of bills and amendments by the US Government. The background of what the bill actually does is of no relevance, but rather how it actually become law. As it turns out, someone “slipped” the bill into the massive group of fixes and proposals and “no one” noticed. Why in the world am I bringing this up? Because Facebook decided that it would be a good idea to try and do the same thing with Android users.
According to an article that went up in reddit yesterday, a blogger found out that the Facebook Android app was about to automatically update itself, when he was prompted to accept some new permissions that had just been added to the app. The very first one: “Read your text messages (SMS or MMS).” It is no secret that Facebook makes a living out of collecting information and using it for targeted advertising. They already have access to all the garbage that we post on our walls, all the times we “check in” anywhere, all the pictures/videos that we upload, and let’s not forget our contacts and what we like and dislike. It is not like they don’t have access to pretty much every part of our lives, so why do they need more?
The comments in the reddit thread linked above seem to suggest that the permissions have been around since the end of December, so it is entirely possible that the upgrade came in the form of a staged rollout to prevent everyone from noticing this change at the same time and causing a fuss. As you would guess, they (Facebook) do have a somewhat of an official explanation for this permission, and that is to scan for SMS confirmation codes. The permission granted is far too broad to be granted to an app whose main function is to collect information about you. This is where selective permissions tools such as App Ops and Xprivacy come in handy. And based on some of the other permissions in the screenshot—well, lets just say that if you use any app on your device, Facebook will know about it. I mean, looking at those permissions, I have gotten rid of Trojans on my PC that used fewer permissions.
So, what options do you have as a user? For starters, if you truly do enjoy using the Facebook official app (not entirely sure why anyone would), you could either stay with it and live with the fact that Facebook will know everything about you or simply try to uninstall it and install a previous version that does not require these permissions. You could also try to block some of these permissions with various privacy suites. And last but not least, you could simply opt for a different Facebook client such as Fast. On the flip side, uninstalling Facebook might give you a nice boost in productivity, as well as battery life.
Being social on the web should not have to be something that we’re afraid of. But companies like Facebook are making it harder every single day, as we cannot even have privacy in the confines of our own virtual domain. Perhaps the best way to be social and share your experiences without being virtually cavity searched would be to host your own blog without a “Facebook” in the domain. Then again, you will still have the NSA to look out for, but that is a rant for another day. You can find the original blog in the following link.
January 10, 2014 By: Will Verduzco
About a month ago, we talked about a recent study (PDF) stating that most security vulnerabilities on Android are ultimately due to OEM customizations. And surprise, surprise—this can even happen on devices with technologies designed to protect users.
Late last month, security researchers at Israel’s Ben-Gurion University of the Negev discovered a security vulnerability that allowed a user-installed application to intercept unencrypted network traffic. Rather than describing this as a flaw or bug, Samsung labels the vulnerability a classic Man in the Middle (MitM) attack, which could be launched at any point on the network.
Samsung was also quick to state that this type of attack can be thwarted using existing KNOX technology (or the device-wide VPN support in stock Android):
Android development practices encourage that this be done by each application using SSL/TLS. Where that’s not possible (for example, to support standards-based unencrypted protocols, such as HTTP), Android provides built-in VPN and support for third-party VPN solutions to protect data. Use of either of those standard security technologies would have prevented an attack based on a user-installed local application.
KNOX offers additional protections against MitM attacks. Below is a more detailed description of the mechanisms that can be configured on Samsung KNOX devices to protect against them:
1. Mobile Device Management — MDM is a feature that ensures that a device containing sensitive information is set up correctly according to an enterprise-specified policy and is available in the standard Android platform. KNOX enhances the platform by adding many additional policy settings, including the ability to lock down security-sensitive device settings. With an MDM configured device, when the attack tries to change these settings, the MDM agent running on the device would have blocked them. In that case, the exploit would not have worked.
2. Per-App VPN — The per-app VPN feature of KNOX allows traffic only from a designated and secured application to be sent through the VPN tunnel. This feature can be selectively applied to applications in containers, allowing fine-grained control over the tradeoff between communication overhead and security.
3. FIPS 140-2 — KNOX implements a FIPS 140-2 Level 1 certified VPN client, a NIST standard for data-in-transit protection along with NSA suite B cryptography. The FIPS 140-2 standard applies to all federal agencies that use cryptographically strong security systems to protect sensitive information in computer and telecommunication systems. Many enterprises today deploy this cryptographically strong VPN support to protect against data-in-transit attacks.
Now before we start bashing Samsung’s KNOX technology more than necessary, let’s remember that these kinds of attacks can affect non-KNOX devices as well. Furthermore, sending personal data in unencrypted form is simply asking for trouble. If anything, this should serve as a reminder to use encrypted transfers and connections whenever possible and to be wary about where we store and input our data.