For a long time Android had a number of “tapjacking” vulnerabilities. They were supposed to be fixed in Marshmallow but they didn’t. Instead users got some awkward permission dialog which can be easily bypassed.
Tapjacking got especially dangerous in Marshmallow with introduction of runtime permission. Now the permission dialog can be hijacked by the malicious app.
You can see a demo of such exploit on my GitHub.
It’s just a demo so not all the alignment, synchronization are perfect but it clearly shows that it’s possible to hijack Marshmallow permission dialogs.
I reported this issue to Google long ago and submitted patches to AOSP Gerrit but apparently they’re not taking it seriously. Maybe by sharing it here at least it’ll get fixed in some open-source ROMs.
Related
I've noticed a few interesting tidbits. There's also lot of things that don't quite match up between the G1 builds and what we get from a git checkout. It might be helpful to build a list.
I was trying to determine the specifics of the update-check process.
The Updater app just displays the nag screen and handles the update process. It's apparently possible for an update to be forced however - concerning. LL
Looking at Logcat reveals that CheckinService is responsible for downloading the updates and sending out the FOTA_READY intent. Trouble is, the only impl of CheckinService is FallbackCheckinService, which is a minimal no-op for everything. Inside of SystemServer, FallbackCheckinService is clearly added as the checkin service. Grepping for various strings like "Sending checkin request" which appear in logcat shows nothing. Apparently, there's a different CheckinService implementation sitting on the G1s -which is strange, as the instantiation of FallbackCheckinService is hard-coded in SystemServer. I'd expect this to be configurable somewhere if vendors are expected to roll their own checkin code.
Note that a checkin goes both ways. Various important events such as crash reports and OTA installs are recorded and then uploaded on the next checkin. New updates are advertised - not sure of anything else the server pushes out. You can see the upload tags (that we know about) in http://android.git.kernel.org/?p=pl...lob;f=core/java/android/provider/Checkin.java
Google Talk has an interesting place in the platform. At some point before the open-source release, there was an API to send data messages or somesuch over gtalk - the documented intention was a means for simple games, etc. However, this API was removed.
If you dig around in the IM app code, it seems that only one protocol provider is included - for IMPS, some retarded standard for mobile IM which apparently delegates things to a carrier provided server. And at the time I saw that, I was saddened in thinking that gtalk on my phone was being done in this manner. But once again, logcat shows something different. There are tags for GTalkService and also Smack going by (the latter being an XMPP lib) so hopefully that is indeed what the IM app is using.
That makes the following file very interesting:
http://android.git.kernel.org/?p=pl...a/com/android/server/MasterClearReceiver.java
MasterClearReceiver takes an intent of type android.intent.action.GTALK_DATA_MESSAGE_RECEIVED, but doesn't check any payload...I thought it must have been some old cruft since thats the only occurrence of GTALK_DATA_MESSAGE_RECEIVED, but the existence of GTalkService on the G1 leads me to think that that intent may actually be generated somewhere.
Checkin also has a method for getting parental control state. Between that and master clear, I wouldn't be surprised to see some kind of control panel available through google at some point for phone management.
From http://source.android.com/roadmap
"Final push of internal code to the open-source repositories
During Android's transition to an open-source project, some development has continued to happen in a private branch. We are working to move the rest of these changes into the open as soon as possible, and all future open-source work will happen in the public git repositories. All changes that have already been submitted to the public repositories will be merged into the newer code base, so nothing should be lost."
Maybe this is the cause of your discoveries?
It's strange that XMPP support would be absent from the repository but on shipping handsets. Google has incentive to NOT encourage use of IMPS on Android handsets, as can be seen with the master clear thing. I'd thinking they'd be pushing hard for it for purposes of remote management and better gtalk integration (think Jingle and voip).
hmmm very interesting
hmmm..Yes yes mr.higgins what do you make of this matter on our grubby hands?
Ace42 said:
hmmm..Yes yes mr.higgins what do you make of this matter on our grubby hands?
Click to expand...
Click to collapse
I do wish I had some of whatever it is that you're smokin'
Hi,
I've recently been paying some attention to privacy-related applications which have been appearing: things like Permission Denied (com.stericson.permissions), Privacy Blocker (com.xeudoxus.privacy.blocker), DroidWall (com.googlecode.droidwall.free) and Connection Tracker (com.borgshell.connectiontrackerfree - I've only just looked at this one).
Each of these applications provides some really good features. Permission Denied is good for blocking certain permissions (though not selecting which permissions at run-time). Privacy Blocker does a great job of identifying the specific operations being attempted within a permission (e.g. getLine1Number etc.) and is pretty good at patching on the phone to provide fake/fixed data. DroidWall is excellent (and I think for most people, entirely sufficient actually, although WhisperMonitor may improve on it). Connection Tracker - I really don't know.
However, each of these have their limitations. Permission Denied isn't very granular with its permissions (although as granular as the Android security model on which it operates). Privacy Blocker is susceptible to code using reflection (I believe) to hide some API calls, as well as requiring the target apps be patched before being run. DroidWall - well, like I said, it's fine.
I was imagining that one way of possibly overcoming some of these limitations would be to intercept API calls made by applications, and then (a) prompt the user as to whether they wanted to allow them and (b) allow the user to choose to always allow, and (c) allow the user to return false/static data and pretend to the calling application that the API call ran fine, etc. With integration with a centralised system it would also be potentially possible to allow a list of API calls used by a program to be generated which would be impervious to call hiding techniques because evenually the API call must be made, no matter how circuitously the call may be constructed.
The question at the heart of this, of course, is this: Does anyone know if API calls in Android can be intercepted without actually having to make a lot of modifications to the guts of Android itself. Chances are I'll probably poke around and have a look myself, but I'm very new to Android development and figured that there may be a good reason no-one has built an application to do specifically this yet and I'd rather find out before I spend a few hundred hours bashing my head against walls someone else has already pounded on.
(Naturally, not all API calls would necessarily be intercepted for all users. If this were to be built into an application, then probably by default only privacy-related calls would be trapped. An approach similar to Privacy Blocker of using baksmali and parsing to identify easily-findable API calls would also allow users to choose which permissions to allow in advance.)
Cheers.
first: I can't add links here since I'm new user, so I'll give you only keywords
I believe that you are looking for the project pffmod
I think the project TaintDroid is the one that you look for run time analysis
If you know some kernel development, I would like to cooperate with you to build a ROM that can intercept applications using API, I also want to create something like Privacy Blocker (static analysis) but instead of patching the application the ROM will give a fake answer or exception or null value or what ever based on rules in a table.
What do you say?
There is also the MockDroid project
This project actually does something like pffmod
I can't check either pffmod or MockDroid since I have Samsung Galaxy.
I'll look into it deeply later on.
Is this something we have to worry about? Or, is it just click-bait?
http://www.wired.com/2016/01/hack-brief-years-old-linux-bug/
AN ISRAELI SECURITY research firm has come forward with a troubling discovery. A zero-day vulnerability in the Linux kernel has left “tens of millions” of Linux PCs and servers exposed, along with 66 percent of Android phones and tablets. And it’s been there for nearly three years.
The Hack
In a blog post detailing the issue, Perception Point researchers say that problem stems from the Linux keyring facility, essentially a locker where apps can stash authentication and encryption keys, security data, and other sensitive info. The bug, outlined in more depth here but described as “fairly straightforward,” can ultimately allow an attacker to pose as a local user and gain root access to a device.
This is bad! Root access can allow an attacker to do everything from installing malicious programs to deleting files to reading sensitive information on the device. Gaining access is also a simple enough matter; an attacker could use a simple phishing link to infiltrate the device.
Who’s Affected?
As far as Perception Point can tell, nobody so far. That’s some comfort, but maybe not much given the large number of potential targets.
“While neither us nor the Kernel security team have observed any exploit targeting this vulnerability in the wild,” says the Perception Point post, “we recommend that security teams examine potentially affected devices and implement patches as soon as possible.”
In addition to the “tens of millions” of Linux PCs and servers running Linux Kernel version 3.8 and higher, because Android shares some code with Linux, the vulnerability affects any Android device running version 4.4 or later. As of January 4, that adds up to 69.4 percent of all Android devices, even more than the researchers estimated. Basically, if you’ve bought or upgraded your Android device within the last two years or so, that device is vulnerable.
Update: Google has responded to Perception Point’s claims; in short, the company has prepared a patch and will make it available to partners today, and says that the range of affected devices may be “significantly smaller than initially reported.”
“We believe that no Nexus devices are vulnerable to exploitation by 3rd party applications,” writes Google’s Adrian Ludwig. “Further, devices with Android 5.0 and above are protected, as the Android SELinux policy prevents 3rd party applications from reaching the affected code. Also, many devices running Android 4.4 and earlier do not contain the vulnerable code introduced in linux kernel 3.8, as those newer kernel versions not common on older Android devices.”
How Serious Is This?
That something this potentially devastating went unnoticed for years is absolutely serious, especially given that Perception Point was able to put together a proof of concept exploit. In terms of actual exposure, the answer is mixed.
Things are already looking up on the enterprise side. Red Hat and Ubuntu have released their updates already, so now it’s just up to admins to implement them.
Android’s a slightly tricker story. While Google recently kicked off a monthly security update program, the company hasn’t yet said if a fix for this particular bug will be included in February’s, if not sooner. Even if it is, the update will need to work its way through the labyrinthine processes of the various carriers and hardware manufacturers that customize the operating system to their own liking. In short, there’s no telling how long it might take for all Android devices to be in the clear, if ever.
The good news is that all you really need to do to protect yourself is avoid suspicious links that might give a malicious actor access to your device. And if and when that security update does come through, install it. ASAP.
Before I begin, I'm not here to flame tbe devs as I would love this app if these issues weren't present and do hope this problem is resolved as a result of bringing it to the attention of the community and hopefully this app's devs.
This application has serious vulnerabilities, some of which should be quite easily patched yet have not been for months to a year or so of them having been made public by a reputable security researcher working for Zimperium.
Login information via the browser is not utilizing a secure form of encryption for both web.airdroid.com or when accessing via local IP despite their SSL cert being valid for *.airdroid.com. The key for the DES encryption being used to hash the password and e-mail being hardcoded into the application despite having a POC for an attack on their users is inexcusable and shows a blatant disregard for their application's level of access as well as their user's safety and security.
My finding (as a security noob) has also deeply disturbed me following no response to bug reports or email contact. While attempting to check out their Windows desktop client, my antivirus discovered the installer attempting to download a variant of adware which monitored the user's activities and provides monetary incentives to developers which include it within their programs and applications. I do understand that if something is free, the product is you. However, I am a paying customer of this service as I'm sure many who use xda would be in an effort to support development of software and applications we enjoy. This adware was ran through and confirmed with VirusTotal and certainly is not a false positive. This desktop client also does not use SSL for communication.
Due to discovering these problems, I immediately discontinued use (the same day I renewed my yearly subscription). However, I was unable to remove the application from my phone without a full factory reset even after both application updates and upgrading android versions. With it set as a device administrator, it's access must first be revoked before uninstalling. However, across multiple devices and versions of android, attempting to remove it from device administrators causes a crash of the android settings app.
I had planned to do a POC for what I feel is an extremely likely scenario based off both public vulnerabilities as well as what I had discovered myself, but I have been far too busy with a few other projects as well as work to complete it yet. I had just stumbled across this section of the xda forums while looking for something else and hoped to get a response from the devs of this app.
I would love to be able to utilize an app with this functionality. However, there needs to be far more focus on security in its design before I would ever feel comfortable utilizing it again.
In theory, it would be entirely possible for an unstable, technically inclined person at a local coffee shop (or other public location with unsecured an wireless network) to hijack a user's login information with minimal skill level required then giving them full, unadulterated access to the application's functions such as forcing gps or camera on to track or watch someone without their consent as all connections aren't even requiring the user to accept the incoming connection on their phone to perform these actions. That is not a farfetched scenario and presents a possible threat to someone's physical safety.
Link to said researcher's findings can be found on his blog by searching Zimperium airdroid multiple vulnerabilities as I just created this account for this post and can not yet post outside links.
Thanks a lot for all this information. I really appreciate it.
Why hasn't this been addressed yet?
I remember reading this a while ago, realizing that it is a serious issue, and just how little the devs care about security on their app.
This is mainly because most end-users don't dive this deep into an app, and don't fully comprehend the severity of such vulnerabilities until it is too late.
We should make a bigger fuss about these things!
I've always been very careful with RAT-type apps and so I was when checking out AirDroid. I've uninstalled it after 30 minutes of using, just because I didn't like the fact, there's a chance some undesirable person could start spying on me. As I read this thread, I'm realising how right I was that time.
Hi there, my organization is a paid user of an app. Prior to the latest version of that app, screenshot ability was possible on Android and iOS devices. However, a recent update disabled the ability to take a screenshot only on Android but not iOS. When I try to take a screenshot, this is the message that a appears on screen: "This action isn't allowed by the app or your organization" I've contacted the app developers and they have said they're working on a solution. This was over a year ago. I've reached out to them recently, and this is their response: "Unfortunately, screenshots are still not available on Android devices. As [name] may have already told you, this lack of functionality is because of a known security issue in Google's OS. We are still actively waiting for Google to update this security flaw so that we can add the feature to our Android app."
Is anyone aware of this security flaw in Android OS that would necessitate the inability to take a screenshot?