[Owasp-leaders] OWASP Mobile Top Ten 2014 - M10 Datapoints

Yvan Boily yvanboily at gmail.com
Wed Nov 5 21:21:30 UTC 2014


Jonathon - I'm a web guy, but I'm also a browser guy, and by extent a
mobile guy (my employer ships both mobile apps and a mobile platform).

Bottom line if you are going to pick on Certificate pinning as being 'weak'
because it relies on hardcoded data you should probably frame it in the
context of the value that the control offers.

Certificate pinning is explicitly designed to make it harder to perform for
someone with control over your network to perform a MITM attack.  In this
case it is a very strong control.  It also remains a strong control in the
case where an attacker has unprivileged code running on the targets device,
however, if the attacker has the ability to run privileged code (including
the privilege of installing or injecting malicious code that removes or
alters the certificate data, or the certificate pinning code) then they win.

The certificate pinning control is only irrelevant if you are assuming an
attacker with the ability to modify local code (either the stored binary,
or in memory).  Before dismissing a security control make sure you frame
the context properly or you run the risk of teaching bad practices to
people coming to OWASP to learn about security, which is pretty much the
opposite of what OWASP sets out to do.

Just my $0.02

On Tue, Nov 4, 2014 at 7:36 PM, Jonathan Carter <jonathan.carter at owasp.org>
wrote:

> While M10 does touch on digital rights management, it goes far beyond
> that.  Here's an easy example: certificate pinning.  Certificate pinning is
> a classic coding technique that relies upon hardcoded data.  This security
> control has an inherent set of other related binary vulnerabilities that
> would allow an attacker to completely bypass or disable your flawlessly
> written code.  You must make it as difficult as possible to prevent someone
> from modifying that hardocded data.  If they do, you've completely made
> your certificate pinning control irrelevant.  This is what M10 is touching
> on and it's something that OWASP really doesn't like to talk about or
> acknowledge.
>
>
> On Tue, Nov 4, 2014 at 7:12 PM, Tim <tim.morgan at owasp.org> wrote:
>
>>
>> Hi Leaders,
>>
>> I have brought up my concerns about M10 before and I have done a fair
>> bit of thinking about this since then.  I think it would be useful to
>> re-frame the discussion with some more subtle distinctions:
>>
>>
>> 0. Are all software security risks also considered business risks?
>>
>>    Yes, I would say so.  It is hard to find a computer security risk
>>    that doesn't pose some kind of business risk.
>>
>>
>> 1. Are all business risks considered security risks?
>>
>>    No, I definitely don't think so.  There are plenty of things
>>    outside of the realm of software security that are very real
>>    business risks (e.g. employees running over a business partner in
>>    the parking lot by accident).
>>
>>
>> 2. Is binary modification/repackaging a real business risk to
>>    intellectual property?
>>
>>    Yes!  It is happening already.  An attacker could repackage your
>>    app, redistribute, and reap benefits from app stores based on your
>>    hard work.
>>
>>
>> 3. How is mobile reverse engineering and/or repackaging a security
>>    risk?
>>
>>    Yes, specifically:
>>
>>    A) Reverse engineering can expose crypto keys and any other secrets
>>       that are foolishly embedded in the app.
>>
>>    B) Repackaging can be used to try and fool users into installing
>>       the wrong version of an application which has malicious intent.
>>       Very similar to phishing.
>>
>>
>> 4. Does mobile app obfuscation/monitoring/anti-reverse engineering
>>    technology help solve a *business* risk?
>>
>>    Yes, in that it raises the cost of reusing the compiled version of
>>    the software.  Raise the cost enough, and the attacker might as
>>    well write their own app.  Even if you don't raise the cost *that*
>>    high, you reduce the number of people willing to target your app
>>    specifically.
>>
>>
>> 5. Does mobile app obfuscation/monitoring/anti-reverse engineering
>>    technology help solve a *security* risk?
>>
>>    No, I don't think so.
>>
>>    Regarding (3A)-- If crypto keys/credentials/etc are valuable, it
>>    doesn't take a whole lot of effort decode an obfuscated binary to
>>    get that them.  Definitely worth the minimal effort.
>>
>>    Regarding (3B)-- If cloning apps like this is effective against
>>    users, then it's just as easy to copy the images from the company's
>>    website, slap it on a "hello world" app, add a login form, and
>>    poof: you have users' credentials.  You don't need to clone a whole
>>    app to fool users.
>>
>>
>>
>>
>> I think many folks on each side of the discussion are correct in what
>> they are saying, but they are talking about different things.  Look at
>> the issue with a slightly higher resolution, particularly in the
>> context of what attacks are actually applicable, and it all becomes
>> much more clear:  Remove M10.  (After all, OWASP is primarily about
>> computer security, not digital rights management.)
>>
>>
>> Cheers,
>> tim
>>
>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20141105/124da019/attachment.html>


More information about the OWASP-Leaders mailing list