Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

Android Apps Slurp Excessive Data

Nearly half of leading Android apps access more types of data than they require, finds a new security study.

10 Ways To Get More From Your Android Device
10 Ways To Get More From Your Android Device
(click image for larger view and for slideshow)
More than one-third of Android apps request "excessive permissions," giving them access to more data than they require.

That finding comes from a study conducted by South Korean antivirus vendor AhnLab, which scanned 178 "best rated" Android applications using its cloud-based Android security scanning service.

All told, of the apps scanned, AhnLab found that 43% requested excessive device information, 39% requested unusual levels of location information, 33% requested excessive access to personal information, and 8% wanted excessive information about service plans.

[ Google's StreetView put data collection above people's security. See Google Wardriving: How Engineering Trumped Privacy. ]

According to HoWoong Lee, director of the AhnLab Security E-Response Center, mobile applications that access excessive amounts of data are a concern because they may have access to banking data and personal emails, or be able to retrieve information that would allow attackers to clone smartphones or sign up mobile subscribers for premium services. Some apps, meanwhile, not only access but also store this sensitive information, oftentimes in unencrypted form. Furthermore, users may not notice any malware that targets sensitive stored information running in the background, surreptitiously siphoning away stored data.

But having legitimate applications access more data than they require would appear to be quite common. That goes not just for legitimate Android apps, as well as malware, but also for iOS apps.

Many social networking applications, including Path and Hipster, were called out earlier this year over revelations that they sent unencrypted copies of iOS users' address books back to their servers. While the developers behind Path defended the practice as a way of helping them connect users who already knew each other, the resulting outcry led the app developer to make the address book sharing "opt in."

Apple likewise weighed in, saying that slurping people's contact information without their permissions would be against its development guidelines. Apple apparently hadn't been testing iOS apps for such behavior as part of its App Store review process.

Not long after, Twitter, Yelp, and Foursquare also came clean, saying that they likewise transmitted users' contact information whenever people selected features with labels such as "find friends." But such information was often stored in unencrypted format, again creating an information security risk.

Apps running on Android or iOS that request, store, or share excessive amounts of information add to already pervasive business concerns over the security of mobile handsets. So, what can be done to address the problem?

One solution for businesses is application whitelisting, which means ensuring that any Android device that wants to connect to the corporate network runs only approved apps. While the practice is controversial, many security experts see it as the best solution for keeping malware and untrusted apps--such as those requesting excessive data access rights--off of Android handsets.

Put an end to insider theft and accidental data disclosure with network and host controls--and don't forget to keep employees on their toes. Also in the new, all-digital Stop Data Leaks issue of Dark Reading: Why security must be everyone's concern, and lessons learned from the Global Payments breach. (Free registration required.)

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/6/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15570
PUBLISHED: 2020-07-06
The parse_report() function in whoopsie.c in Whoopsie through 0.2.69 mishandles memory allocation failures, which allows an attacker to cause a denial of service via a malformed crash file.
CVE-2020-15569
PUBLISHED: 2020-07-06
PlayerGeneric.cpp in MilkyTracker through 1.02.00 has a use-after-free in the PlayerGeneric destructor.
CVE-2020-7690
PUBLISHED: 2020-07-06
It's possible to inject JavaScript code via the html method.
CVE-2020-7691
PUBLISHED: 2020-07-06
It's possible to use <<script>script> in order to go over the filtering regex.
CVE-2020-15562
PUBLISHED: 2020-07-06
An issue was discovered in Roundcube Webmail before 1.2.11, 1.3.x before 1.3.14, and 1.4.x before 1.4.7. It allows XSS via a crafted HTML e-mail message, as demonstrated by a JavaScript payload in the xmlns (aka XML namespace) attribute of a HEAD element when an SVG element exists.