Saying “was hacked” covers up the fact that Richard Engel hacked himself by knowingly downloading a hostile Android app.

via Errata Security: That NBC story 100% fraudulent (how passive voice tells you someone is bending the truth).

Color me exceptionally unsurprised. Apparently both the Android and OS X “hacks” required him to manually force a malicious app to run.

There is, however, a valid point that some people do allow third party and/or unsigned applications to run on their devices (while this is less common on mobile devices than on PC platforms, third party markets require turning off code signing on Android, opening a large attack surface).

App reviews, usable workflows, and feedback loops

There’s been a lot of discussion lately about iOS apps showing users modal dialogues requesting that they rate the app on the App Store. Like this (from Eff Your Review):

effyr_instagrameffyr_vineeffyr_facebook

The forces encouraging this behavior are complex, and relate to issues of discoverability and ranking in the App Store. There’s been debate about how to curtail these1.

My lab likes to think about app markets as a place where feedback loops exist, and part of our research into improving the security and privacy of apps (particularly with permission systems) relies on feedback from a user affecting the marketplace itself. Here’s a flowchart of the entire thing from one of David Wagner’s overview talks:

App Flowchart

There’s been work to provide tools to improve apps (to help developers reduce overprivileging their apps2, to detect insecure use of APIs3, etc.), or to improve the platform4 (making permissions clearer, showing warnings to users at the right time, avoiding habituation). But we make a big assumption:

Not all users need to notice or understand all warnings or notifications for these new systems to be effective — if some fraction of users do notice, and provide feedback back into the marketplace or to the developers when undesirable behavior occurs, then these systems can still have a positive effect on the quality of apps on a platform.

This assumption is primarily based on research that shows that app reviews are one of the most significant factors in a user’s decision to install an app5. So if some users notice misbehaviors or warnings, and understand them, then they can write good reviews using them, helping all of the novice users that only look over reviews when considering apps.

But is this actually enough? Can we really say that because some users could write better reviews that our work could actually lead to better app markets?

The recent app rating brouhaha seems particularly relevant. App markets and platforms need to help out enough to make this work:

  • Users need to be encouraged to write reviews. This is particularly important for apps that user don’t keep installed.
  • Useful reviews should be easy to write. Platforms probably need to hold users’ hands.
  • Reviews need to be easy to read, with useful information pulled out for easy access to users skimming applications. App markets need to be more like Amazon than the iOS App Store: ranking reviews on recency and usefulness, pulling out key points common across a lot of reviews, verified reviews, etc.
  • Fake reviews and ratings need to be curbed. This includes apps begging for reviews.
  • Rankings and listings in the market should be holistic and well-developed.

We don’t really have any of this on any mobile platform currently, but I think any of them would make for a much better app market.

Footnotes

  1. Can Apple ban them? I’d argue you could get pretty far with static analysis tools, but that’s for another post… ^
  2. Android Permissions Demystified, by Adrienne Porter Felt et al., developed a tool called Stowaway to detect overprivileged of android apps. ^
  3. Analyzing Inter-Application Communication in Android, by Erika Chin et al., developed comdroid to detect insecure use of intents. ^
  4. A lot of work has been done on redesigning permission systems for Android: What’s wrong with permissions, how to ask for permission for different resources, the benefits of automatically granting low risk permissions, etc. This has been a big research area for students of my advisor, David Wagner, and the SCRUB center. ^
  5. Android permissions: user attention, comprehension, and behavior, by Adrienne Porter Felt et al., SOUPS ’12. ^

RdRand and Linux

It’s being discussed again, because apparently someone decided to start a Change.org petition, to which Linus Torvalds has responded (in typical Linus fashion).

From what I’ve seen, it started with some discussion on the mailing list where people speculated on the dangers of using RdRand to feed the Linux entropy pool (and speculation about it being used exclusively for things like ASLR), and ended up discussing more subtle microcode level attacks.

Beyond people not understanding how XOR works, and the fact that bits from RdRand are just getting mixed into the entropy pool as yet another source (and, if you’re using /dev/urandom as you should be, you only need a small amount of re-seeding to maintain your cryptographic security), it seems that the NSA backdooring the Linux PRNG would just be attacking crypto for the sake of attacking crypto. Less polite company have words for that.

If you have the ability to backdoor a CPU instruction, why do it in what might be the most roundabout way possible? Why not just extract keys from memory? And if you’re going to attack crypto, going through biasing some bits of the entropy pool seems much, much harder than is necessary. I think this is well summed up in this tweet:

 

Breaking Cell Phone Authentication: Vulnerabilities in AKA, IMS and Android

Last year, I worked on reverse engineering Android implementations of IMS, the next generation 4G IP based telephony suite of protocols, with Jethro Beekman at Berkeley.
In addition to our technical report on MITM vulnerabilities against T-Mobile’s Wi-Fi Calling feature (due to unvalidated SSL certificates), we continued to look at IMS systems in general, and how T-Mobile and Android implemented them. We found that, amongst other things, Digest AKAv1, the authentication and key exchange protocol used in IMS, doesn’t correctly require use of the generated secret keys, allowing a variety of attacks. Furthermore, generally accessible APIs in both core Android and in T-Mobile’s customized ROMs allow apps with just the READ_PHONE_STATE permission to access the IMS authentication routines in the SIM card, making it possible for low-privilege malware on a phone to let a remote attacker authenticate as that phone.

A simple example of why you might care: An attacker can pretend to be you (your number, your subscriber ID, your phone) and call premium 1-900 numbers or send text premium text messages, costing you real money.

Jethro presented our paper at USENIX WOOT (Workshop On Offensive Technologies) 2013 a couple weeks ago. The paper, slides, and video of the talk (thank you USENIX open access policies!) are available at https://www.usenix.org/conference/woot13/breaking-cell-phone-authentication-vulnerabilities-aka-ims-and-android.

We released a technical report on our MITM attack against T-Mobile’s WiFi Calling service, which I realized I never linked to this here. This was joint work with Jethro Beekman, another EECS grad student at Berkeley. Big takeaway: T-Mobile was great to work with on fixing this vulnerability—their security team is excellent.

We also have a WOOT 2013 paper that covers this and other attacks on cellular systems, but we are still working with vendors on that. Stay tuned.

Update (2013/9/6): Our WOOT 2013 paper is published, and I’ve posted some details and links to the paper, slides, and video.

Lukas Mathis on the mysterious Gmail checkbox-with-dropdown, and why empirical design is important:

“What Leggett described is exactly how I felt about the widget when I first saw it. I immediately figured out how to use it, but my gut reaction was «most people are not going to get how this works.» It seems I was wrong. This is one of the reasons why I don’t put too much trust into opinion-based usability reviews: There’s a lot of guesswork involved, and guessing how humans behave is an endeavor fraught with peril.”

“Would you like a pocket-size device that reminded you of each appointment and daily event? I would. I am waiting for the day when portable computers become small enough that I can keep one with me at all times. I will definitely put all my reminding burdens upon it. It has to be small. It has to be convenient to use. And it has to be relatively powerful, at least by today’s standards. It has to have a full, standard typewriter keyboard and a reasonably large display. It needs good graphics, because that makes a tremendous difference in usability, and a lot of memory—a huge amount, actually. And it should be easy to hook up to the telephone; I need to connect it to my home and laboratory computers. Of course, it should be relatively inexpensive.

What I ask for is not unreasonable. The technology I need is available today. It’s just that the full package has never been put together, partly because the cost in today’s world would be prohibitive. But it will exist in imperfect form in five years, possibly in perfect form in ten.”

Donald Norman, “Design of Everyday Things”

Ant colony optimization

I’ve been looking at ant-algorithms for pathfinding lately. They’re interesting because they are very simple multi-agent search, but some of the benefits that I originally thought it might have (dealing with imperfect last-known-information, dynamic environment, etc.) seem to be negated by the fact that it isn’t terribly great when you don’t have a ton of agents.

I’ll have a more concrete idea of how feasible ant-algorithms are once my implementations are done and I can run simulations. Never hurts to separate the hype from the substance, though.

Update (2011-12-31): We ended up implementing some various pathfinding mechanisms for many-agent movement in a semi-unknown environment. Turns out that ant colony optimization is actually not so great… at least in the classic “pathfinding” sense. Convergence is slow, the actual amount of shared information is weak, etc. The test program is at least pretty, thanks to wxPython. The settings are all at the top of the Python script, and a little arcane, but you can run it with

python sim.py

You can download the program here: sim.py

From mrgan.tumblr.com:

Another much-linked chart, this one deemed beautiful enough to grace the cover of a book. An appealing image, certainly. I’m not sure how it relates to flowers, but ok.

Now let’s try using the actual chart. Find what the cultural significance of red is in the Muslim culture. No? Ok, it doesn’t work that way – let’s instead find what color symbolizes peace in Eastern European cultures. Find it yet? Need a compass, perhaps, to trace from the in-chart legend to the desired slice?

Please stop the madness. The purpose of a chart is to illuminate; if it’s harder to read than a raw-data table or a paragraph of text saying the same, then don’t use a chart. And if your goal is simply to create a pretty graphic, then don’t try beefing up your science cred with this “information” stuff.

Arranging data in an aesthetically pleasing way with no regard for how the arrangement affects the viewer’s understanding is simply dishonest. It’s only popular because no one really cares to use these charts for any real purpose. (Color significance in cultures – I mean, does it get any fluffier?) Imagine someone with no database experience “visualizing” a SQL query in this way and trying to sell a database administrator on it.

Information can be beautiful. Information can also be ugly. It can be helpful or misleading, educational or confusing. Information doesn’t care; the designer has to.

The chart is question is definitely good looking. I’ve made good looking figures (not with as much art to them).

The point I get out of this: the chart isn’t designed.

It’s simply made to look good.

But can this chart be designed? The post on Neven Mrgan’s Tumblr argues that the data doesn’t work in a chart.

Too often school assignments I’ve had require figures/charts, and looking back, these really often were unnecessary, redundant, etc. Almost all of them fell under the “harder to read than a raw-data table or a paragraph of text saying the same“. The issue was that there was no freedom in the assignment to makedesign choices. And there certainly wasn’t design thought going into the construction of most of the assignments, either.