The Audacity of Your Flashlight App

I've been taking a closer look at my mobile apps lately, specifically the permissions they request when downloading and installing them.  It has been quite an eye opener.  It turns out that mobile apps are invading our privacy.  It's as simple as this: any app that can read your contacts and access the Internet can slurp your data and send it off to some random server to be stored and/or used in a nefarious way.

The finding that surprised me the most was the audacity of my little old flashlight app.  I was using "Tiny Flashlight + LED", which is allowed to read your phone identity and have full Internet access.  A flashlight app that needs Internet access is nonsensical to me.  I switched to use OI Flashlight, which requires only the permissions of camera control and preventing the device from sleeping.  I discovered during my research that most flashlight apps want Internet access.  The top 4 flashlight apps that appear when searching for "flashlight" on Google Play are:

1. Tiny Flashlight + LED
2. Brightest Flashlight Free
3. Flashlight
4. Color Flashlight

All four require Internet connectivity!  However, the winner of the most inappropriate and egregious permissions contest is "Brightest Flashlight Free" by Goldenshores Technologies, LLC.  This popular app (over 10 million downloads) requires the following permissions:

• full Internet access
• your location (both coarse and fine)
• modify your SD card contents
• read your phone identity

Can you think of a reason a flashlight app needs to know your current location or modify the data on your SD card?  I can't either.

Risky to Report Website Vulns

The main reason I stopped reporting vulnerabilities to website owners is the risk of being prosecuted.  The Internet is more dangerous when well-meaning security researchers are treated this way.  I was new to Application Security in 2006, so I didn't realize that I was actually taking a pretty big risk when I told Netflix about their CSRF vulnerabilities.  In my mind I was doing them a favor.  They got a free mini pen test.  In fact as a Netflix subscriber, I was giving them money!  It turns out they were nice and simply said "thank you", then went about fixing the issue.

Today I ran across Patrick Webster's story from Australia and he wasn't so lucky.  He noticed that his bank's web application allowed for any customer to view another customer's account information, including very sensitive data that could allow for identity theft.  This type of insecure direct object reference vulnerability is very simple to exploit.  Mr. Webster just changed a numerical parameter in the URL to discover the problem.  He reported it to his bank, who decided to report him to the police.  It's not like this guy was a determined attacker with premeditation who spent weeks doing reconnaissance on the site.  That said, he clearly went too far by running a script that "cycled through each ID number and pulled down the relevant report to his computer".  That wasn't necessary to report the vulnerability.

Another example is Andrew Auernheimer who is potentially facing 5 years in prison due to his AT&T "account slurper" script.  Again, he went too far with the script, but clearly he might've been prosecuted anyway.  One of the comments on this story was humorous:

You seem to be implying that every exploit can be anticipated. The article points out that AT&T changed their code after discovery of the hack. There is no indication that they knew it was a problem before hand.

Web app vulns can and should be anticipated.