... all the apps on the Android Market get access permissions from Android's built-in security, which is so flawed it can't stop applications from improperly accessing data even when they don't intend to. So, if Google gets rid of all the apps Android would allow to access data improperly, it will be getting rid of all the apps.
> ... all the apps on the Android Market get access permissions from > Android's built-in security, which is so flawed it can't stop applications > from improperly accessing data even when they don't intend to. So, if > Google gets rid of all the apps Android would allow to access data > improperly, it will be getting rid of all the apps.
"[Dizon] also suggested that the issue with capturing data is more to do with the way Android app permissions work, not with any functionality MobClix or Velti has added to apps. Android permissions often grant access to chunks of information rather than a single piece of data. Therefore, in some cases, apps that would like permission to access a single piece of data technically have access to other stuff because of Android's permission system," she wrote. "There is nothing we can do about that."
> ... all the apps on the Android Market get access permissions from > Android's built-in security, which is so flawed it can't stop applications > from improperly accessing data even when they don't intend to. So, if > Google gets rid of all the apps Android would allow to access data > improperly, it will be getting rid of all the apps.
Paul Brodeur, security researcher with Leviathan Security Group, has created a proof-of-concept app that shows how an Android application which doesnt ask for any security permissions is still able to get access to data stored on SD cards, data stored on the handset by other apps, and information about the handset and handsets Android ID. ...
It's interesting that people are making a fuss over the Android_ID though: << The Android ID could be used as a way to identify a specific handset. >> Especially since it is _meant_ to be used to identify a specific handset and not require extra permissions (like the IMEI/IMSI). This value is also changed on each factory reset of a device.
> > ... all the apps on the Android Market get access permissions from > > Android's built-in security, which is so flawed it can't stop > applications > > from improperly accessing data even when they don't intend to. So, if > > Google gets rid of all the apps Android would allow to access data > > improperly, it will be getting rid of all the apps.
> Paul Brodeur, security researcher with Leviathan Security Group, has > created a proof-of-concept app that shows how an Android application > which doesnt ask for any security permissions is still able to get > access to data stored on SD cards, data stored on the handset by other > apps, and information about the handset and handsets Android ID. > ...
> -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To post to this group, send email to > android-security-discuss@googlegroups.com. > To unsubscribe from this group, send email to > android-security-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/android-security-discuss?hl=en.
The readIdentifiers() method in NoPermissionsActivity.java is calling:
- TelephonyManager.getNetworkOperator(): "Returns the numeric name (MCC+MNC) of current registered operator." This is the Mobile Country Code (MCC) and Mobile Network Code (MNC), which is only going to say what country and cellular provider you are on (e.g., AT&T, T-Mobile). It's not very specific to a handset, and therefore a very low privacy risk.
- TelephonyManager.getSimOperator(): "Returns the MCC+MNC (mobile country code + mobile network code) of the provider of the SIM."
- Settings.Secure.ANDROID_ID: As Tim Strazzere indicated in his reply, this is readable without a permission *by design*. Note that the ANDROID_ID is different than IMEI/IMSI, because you can change it without purchasing a new handset.
The readVersion() method is getting the value of /proc/version, which is the kernel version (not sensitive).
The stealAppData() method gets the list of installed packages from /data/system/packages.list (also available from PackageManager.getInstalledPackages() without a permission). It then looks for app home directories that are readable (i.e., on the SDCard). The SDCard is well known to be insecure for storing information, and apps have to specify if they can be loaded to the SDCard, *and* the user has to move them there. As for access to the SDCard without a permission, see the next point.
The stealSD() method goes through all the files in /sdcard and just sends a list of files. Android has no limitations on applications reading the contents of the SDCard. While this is a well known fact, there was another story recently about the concern over apps stealing photos that caused a lot of hype, and IIRC, Google responded that they are working on it. This fix is going to take some time due to legacy compatibility, but hopefully now that Android 3.0 and later connect to PCs using MTP and not a USB mass storage device, there's an opportunity to use file permissions on the SDCard. So yes, this is something that really needs to be fixed, but it's not a new finding (it's been the elephant in the room since day one of Android).
The sendGzByBrowser() and sendByBrowser() just take the acquired information and include it in a URL passed to the Web Browser. This method of exfiltrating data is well known (Tim includes a link on implementing a root shell using this method).
Thanks, -Will
On Apr 12, 2012, at 5:25 PM, Jeffrey Walton wrote:
> A new twist just arrived (or it looks new to me). An app with no > permissions gets pseudo-READ_PHONE_STATE for free.
> Paul Brodeur, security researcher with Leviathan Security Group, has > created a proof-of-concept app that shows how an Android application > which doesnt ask for any security permissions is still able to get > access to data stored on SD cards, data stored on the handset by other > apps, and information about the handset and handsets Android ID. > ...
-- William Enck Assistant Professor Department of Computer Science North Carolina State University Email: e...@cs.ncsu.edu Web: http://www.enck.org
> The sendGzByBrowser() and sendByBrowser() just take the acquired information and include it in a URL passed to the Web Browser. This method of exfiltrating data is well known (Tim includes a link on implementing a root shell using this method).
I think you're incorrect, the article isn't written as FUD. Some media outlets don't understand, and so they throw around titles like "Major Android Vulnerability" and similar garbage. The purpose and tone of the article is to document and inform. Yes, I agree, none of this is news to someone with intimate knowledge of the Android API, like the folks on this list.
The fact that 2-way communication with the Internet is possible without INTERNET permission, and that it's been publicly discussed for 2 years, is exactly the type of thing that should have attention brought to it. Maybe the android.intent.category.BROWSABLE Intent should be restricted? Or maybe there should be a OPEN_BROWSER permission? However it's done in the future, I think the current situation is rather serious.
Those who've read the Android documentation know that SD/External storage shouldn't be used for anything sensitive and that any app can read it. Great. But what about the millions of non-developer Android users? Do they know that a random app can access their backups, upload their pictures somewhere, etc.?
FYI, stealAppData() actually looks in /data/data/<packagename> for readable data. The purpose of this was to find apps that use world-readable permission on their files, such as the Skype vulnerability linked in the article or the Lookout vulnerability from last year: http://blog.mylookout.com/look-11-001/ -- these are not Android OS vulnerabilities, they are vulnerabilities in apps that specifically go against the suggestions in the documentation. I don't think it's stated any differently in the article.
> The readIdentifiers() method in NoPermissionsActivity.java is calling:
> - TelephonyManager.getNetworkOperator(): "Returns the numeric name > (MCC+MNC) of current registered operator." This is the Mobile Country Code > (MCC) and Mobile Network Code (MNC), which is only going to say what > country and cellular provider you are on (e.g., AT&T, T-Mobile). It's not > very specific to a handset, and therefore a very low privacy risk.
> - TelephonyManager.getSimOperator(): "Returns the MCC+MNC (mobile country > code + mobile network code) of the provider of the SIM."
> - Settings.Secure.ANDROID_ID: As Tim Strazzere indicated in his reply, > this is readable without a permission *by design*. Note that the ANDROID_ID > is different than IMEI/IMSI, because you can change it without purchasing a > new handset.
> The readVersion() method is getting the value of /proc/version, which is > the kernel version (not sensitive).
> The stealAppData() method gets the list of installed packages from > /data/system/packages.list (also available from > PackageManager.getInstalledPackages() without a permission). It then looks > for app home directories that are readable (i.e., on the SDCard). The > SDCard is well known to be insecure for storing information, and apps have > to specify if they can be loaded to the SDCard, *and* the user has to move > them there. As for access to the SDCard without a permission, see the next > point.
> The stealSD() method goes through all the files in /sdcard and just sends > a list of files. Android has no limitations on applications reading the > contents of the SDCard. While this is a well known fact, there was another > story recently about the concern over apps stealing photos that caused a > lot of hype, and IIRC, Google responded that they are working on it. This > fix is going to take some time due to legacy compatibility, but hopefully > now that Android 3.0 and later connect to PCs using MTP and not a USB mass > storage device, there's an opportunity to use file permissions on the > SDCard. So yes, this is something that really needs to be fixed, but it's > not a new finding (it's been the elephant in the room since day one of > Android).
> The sendGzByBrowser() and sendByBrowser() just take the acquired > information and include it in a URL passed to the Web Browser. This method > of exfiltrating data is well known (Tim includes a link on implementing a > root shell using this method).
> Thanks,
> -Will
> On Apr 12, 2012, at 5:25 PM, Jeffrey Walton wrote:
> > A new twist just arrived (or it looks new to me). An app with no
> > permissions gets pseudo-READ_PHONE_STATE for free.
> > ""No permissions" Android app allows secret data harvesting,"
> > Paul Brodeur, security researcher with Leviathan Security Group, has
> > created a proof-of-concept app that shows how an Android application
> > which doesnt ask for any security permissions is still able to get
> > access to data stored on SD cards, data stored on the handset by other
> > apps, and information about the handset and handsets Android ID.
> > ...
> -- > William Enck
> Assistant Professor
> Department of Computer Science
> North Carolina State University
> Email: e...@cs.ncsu.edu
> Web: http://www.enck.org
On Friday, April 13, 2012 8:45:02 AM UTC-6, Will Enck wrote:
> Jeffrey,
> Please correct me if I'm wrong, but this article is a bunch of FUD.
> The readIdentifiers() method in NoPermissionsActivity.java is calling:
> - TelephonyManager.getNetworkOperator(): "Returns the numeric name > (MCC+MNC) of current registered operator." This is the Mobile Country Code > (MCC) and Mobile Network Code (MNC), which is only going to say what > country and cellular provider you are on (e.g., AT&T, T-Mobile). It's not > very specific to a handset, and therefore a very low privacy risk.
> - TelephonyManager.getSimOperator(): "Returns the MCC+MNC (mobile country > code + mobile network code) of the provider of the SIM."
> - Settings.Secure.ANDROID_ID: As Tim Strazzere indicated in his reply, > this is readable without a permission *by design*. Note that the ANDROID_ID > is different than IMEI/IMSI, because you can change it without purchasing a > new handset.
> The readVersion() method is getting the value of /proc/version, which is > the kernel version (not sensitive).
> The stealAppData() method gets the list of installed packages from > /data/system/packages.list (also available from > PackageManager.getInstalledPackages() without a permission). It then looks > for app home directories that are readable (i.e., on the SDCard). The > SDCard is well known to be insecure for storing information, and apps have > to specify if they can be loaded to the SDCard, *and* the user has to move > them there. As for access to the SDCard without a permission, see the next > point.
> The stealSD() method goes through all the files in /sdcard and just sends > a list of files. Android has no limitations on applications reading the > contents of the SDCard. While this is a well known fact, there was another > story recently about the concern over apps stealing photos that caused a > lot of hype, and IIRC, Google responded that they are working on it. This > fix is going to take some time due to legacy compatibility, but hopefully > now that Android 3.0 and later connect to PCs using MTP and not a USB mass > storage device, there's an opportunity to use file permissions on the > SDCard. So yes, this is something that really needs to be fixed, but it's > not a new finding (it's been the elephant in the room since day one of > Android).
> The sendGzByBrowser() and sendByBrowser() just take the acquired > information and include it in a URL passed to the Web Browser. This method > of exfiltrating data is well known (Tim includes a link on implementing a > root shell using this method).
> Thanks,
> -Will
> On Apr 12, 2012, at 5:25 PM, Jeffrey Walton wrote:
> > A new twist just arrived (or it looks new to me). An app with no
> > permissions gets pseudo-READ_PHONE_STATE for free.
> > ""No permissions" Android app allows secret data harvesting,"
> > Paul Brodeur, security researcher with Leviathan Security Group, has
> > created a proof-of-concept app that shows how an Android application
> > which doesnt ask for any security permissions is still able to get
> > access to data stored on SD cards, data stored on the handset by other
> > apps, and information about the handset and handsets Android ID.
> > ...
> -- > William Enck
> Assistant Professor
> Department of Computer Science
> North Carolina State University
> Email: e...@cs.ncsu.edu
> Web: http://www.enck.org
Paul Brodeur wrote: > The purpose of this was to find apps that use world-readable > permission on their files, such as the Skype vulnerability linked in the > article or the Lookout vulnerability from last year: > http://blog.mylookout.com/look-11-001/ -- these are not Android OS > vulnerabilities, they are vulnerabilities in apps that specifically go > against the suggestions in the documentation. I don't think it's stated any > differently in the article.
Does that include all apps that allow moving to the msdos filesystem sdcard? Maybe android should use some sort of RBAC as mandating a non dos filesystem like nexus uses looks troublesome to me for those who want to use the card directly.
> ... all the apps on the Android Market get access permissions from > Android's built-in security, which is so flawed it can't stop applications > from improperly accessing data even when they don't intend to. So, if > Google gets rid of all the apps Android would allow to access data > improperly, it will be getting rid of all the apps.
"Accelerometer and orientation sensor data are not protected under Android's security model, and this means that they are exposed to any application, regardless of its permissions on the system, the research team said in a paper that was presented during the ACM Conference on Security and Privacy in Wireless and Mobile Networks on Tuesday."
> ... all the apps on the Android Market get access permissions from
> Android's built-in security, which is so flawed it can't stop applications
> from improperly accessing data even when they don't intend to. So, if
> Google gets rid of all the apps Android would allow to access data
> improperly, it will be getting rid of all the apps.
Some people want to cut Google some slack, since the Android platform
is relatively new. The security issues can be worked on and rectified.
However, Android isnt just failing at keeping developers from
creating harmful apps, its also failing at controlling what
permissions normal apps are acquiring. No permission apps have the
ability to get access to things that have nothing to do with them. For
example, the Facebook app has access to your text messages, even
though it has nothing to do with them. An app may ask for obvious
permission which it requires to work, but can secretly gain access to,
something as off limits as your SD card. A users sensitive data can
very easily make its way into someone elses hands....
---------- Forwarded message ----------
From: Nikolay Elenkov <nikolay.elen...@gmail.com>
Date: Tue, May 8, 2012 at 10:55 AM
Subject: Re: [android-security-discuss] Re: Call for Action: Android Permissions
To: noloa...@gmail.com
On Tue, May 8, 2012 at 4:58 AM, Jeffrey Walton <noloa...@gmail.com> wrote:
No offence, but this article is complete BS. The author is not only clueless,
but his 'writing' is severely lacking: how does listing a bunch of completely
unrelated 'things' under nonsensical headings make an article?
Facebook a 'no-permission' app? 'The system files of an Android'? Really?
If you want to spread FUD, at least make sure it half-coherent before
posting.
> No offence, but this article is complete BS. The author is not only clueless,
> but his 'writing' is severely lacking: how does listing a bunch of completely
> unrelated 'things' under nonsensical headings make an article?
> Facebook a 'no-permission' app? 'The system files of an Android'? Really?
> If you want to spread FUD, at least make sure it half-coherent before
> posting.
Android has a serious problem with their capabilities permissions (or
lack thereof), not the UriPermissions. The problem is clearly chronic
for consumers since Google is not evolving the platform for the
security needs of the users. Perhaps Google's strategy is apply the
Ostrich Algorithm - in which case Its not going to get better on its
own.
That the "author is clueless [sic]" speaks volumes to the breadth of
the problem. Its sad when media managers and clueless tech reporters
even realize there are issues, yet the security and architecture folks
who are responsible for platform security allow the problem to fester.
Its very unfortunate current users are asked to live with a
model/granularity that is years old just so Google can provide
backwards compatibility for dated APIs and applications. I personally
don't like being sacrificed and store no personal information on the
device. Business material is clearly out of the question.
Its is also causing problems for many folks in the Enterprise,
including the folks who have to try to secure the devices (speaking
from experience). In fairness to Google, the company may want to be a
"consumer electronics company" so that the Enterprise does not matter.
This position is not new and has been used successfully by another
popular player. Google's lack of an Enterprise management tool for
centralized administration seems to point in this direction.
Google's Market is quickly becoming like a Linux repository -
hundreds/thousands of useless, broken, or insecure applications. And
many of the apps are not to blame since Google controls the platform.
In that posting, I discuss a vulnerability in the ping binary as it exists in the 2.3 branch. The vulnerability is that ping can be executed without being in the "inet" or similar group. As such, an app with no permissions is able to have limited network access, capable of performing DNS lookups and sending ICMP Echo packets. As I mention in the blog post, this was patched in the 4.0 branch.
My question to the folks on this list is whether this vulnerability was ever discussed, or if it was just silently patched.
Further, am I correct in assuming that security vulnerabilities like this don't get backported? Considering that more than 90% of devices are running 2.3.x or below (as of May 1, according to android.com), this seems like a terrible patch policy.
Paul Brodeur wrote:
> Further, am I correct in assuming that security vulnerabilities like this > don't get backported? Considering that more than 90% of devices are running > 2.3.x or below (as of May 1, according to android.com), this seems like a > terrible patch policy.
Yeah Sony promised me fast updates when I bought. They changed that to
Neo V and Neo by the end of April. Still not to be seen. I wonder if
the 'tested' version will be unpatched.
Makes me consider though not for long right now spending time I
don't have rooting and modding!! I'd get a firewall atleast and maybe
decent anti-theft as my Sister recently had happen. Might of caught the
Bęstard.
> ... all the apps on the Android Market get access permissions from
> Android's built-in security, which is so flawed it can't stop applications
> from improperly accessing data even when they don't intend to. So, if
> Google gets rid of all the apps Android would allow to access data
> improperly, it will be getting rid of all the apps.
I'm not quite sure this is the place to post this,
but I'm proper curious:
I looked into installing the security key app last
night as I'd like the extra layer of security. So I
went to the Android store and looked it up.
Pressed download. Being the paranoid person I
am I looked over the permissions before installing.
I'm glad I did.
Why on Earth does the app need to read my phone
state? That seems really, really invasive to be frank.
I'd love to install it, but no way am I giving anyone
access to my phone calls or the numbers in my phone
book.
Any chance of updating the permissions so it's not a
Stasi app anymore?
> ... all the apps on the Android Market get access permissions from
> Android's built-in security, which is so flawed it can't stop applications
> from improperly accessing data even when they don't intend to. So, if
> Google gets rid of all the apps Android would allow to access data
> improperly, it will be getting rid of all the apps.
...
According to Lookout, the RuFraud application scam targeted
people in 18 countries, including not just Britain, but also France,
Germany, Israel, Latvia, Poland, and Russia, although not the
United States. But it's unclear how many people in the other 17
targeted countries may have been affected by the malware.
"It was very clever, it picked up on the correct country code based
on which type of SIM card was in the phone," said the PhonepayPlus
spokesman. He said his agency had informed other countries about
the results of its investigation.
I believe the fraudulant software implicates READ_PHONE_STATE
> ... all the apps on the Android Market get access permissions from
> Android's built-in security, which is so flawed it can't stop applications
> from improperly accessing data even when they don't intend to. So, if
> Google gets rid of all the apps Android would allow to access data
> improperly, it will be getting rid of all the apps.
To be fair, this app asked for the world and some users agreed. Taking
READ_PHONE_STATE away (or decomposing its permissions) would have only
lessened the impact.
