Jeffrey,

Please correct me if I'm wrong, but this article is a bunch of FUD.

The article includes a link to the source code: 
http://leviathansecurity.com/blog/uploads/NoPermissions.zip

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,"
> http://www.zdnet.com/blog/hardware/no-permissions-android-app-allows-secret-data-harvesting/19709
> 
> Paul Brodeur, security researcher with Leviathan Security Group, has
> created a proof-of-concept app that shows how an Android application
> which doesn’t 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 handset’s Android ID.
> ...



-- 
William Enck
Assistant Professor
Department of Computer Science
North Carolina State University
Email: [email protected]
Web: http://www.enck.org

-- 
You received this message because you are subscribed to the Google Groups 
"Android Security Discussions" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/android-security-discuss?hl=en.

Reply via email to