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

Jonathan Carter jonathan.carter at owasp.org
Wed Nov 5 11:30:21 UTC 2014


Distribution of modifications is a whole other kettle of fish. There's a
number of different means that attackers distribute changes.  Typically,
they'll modify, repackage, and then distribute via either iTunes, Google
Play, or third-party stores. There's also the avenue of direct infection.
Which then goes into the runtime self-modification detection side of life.

On Wed, Nov 5, 2014 at 2:37 AM, Jim Manico <jim.manico at owasp.org> wrote:

>  I do not see *self* man-in-the-middle as a serious risk.
>
> Now if the attacker can modify the mobile app of a victim and change the
> pinned cert of other clients, that is a big deal. But my understanding is
> that is not the scenario Jonathan was referring to, if so please elaborate
> how that would work...
>
> Again, a pinned cert is NOT private data. It's a *public* cert signed by
> an authority. (Or a hash of a signed public cert like the experimental IETF
> headers for browsers :
> https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/)
>
> Aloha,
> Jim
>
>
>
> On 11/5/14 5:28 PM, Erwin Geirnaert wrote:
>
>  Man-in-the-middle
>
>
>
> *From:* owasp-leaders-bounces at lists.owasp.org [
> mailto:owasp-leaders-bounces at lists.owasp.org
> <owasp-leaders-bounces at lists.owasp.org>] *On Behalf Of *Jim Manico
> *Sent:* 05 November 2014 10:15
> *To:* Jonathan Carter
> *Cc:* OWASP Leaders
> *Subject:* Re: [Owasp-leaders] OWASP Mobile Top Ten 2014 - M10 Datapoints
>
>
>
> So, if the attacker modifies their own pinned certificate in a mobile app,
> what do they accomplish? The inability to use that webservice. What is
> accomplished from a security point of view? Nothing....
>
> - Jim
>
> On 11/5/14 4:38 PM, Jonathan Carter wrote:
>
>  In that particular case, the attacker will perform static analysis,
> identify the sensitive code associated with the hardcoded data, and then
> modify the actual data values.
>
>
>
> On Tue, Nov 4, 2014 at 11:41 PM, Jim Manico <jim.manico at owasp.org> wrote:
>
>  Certificate pinning does hard-code •secrets•, it hard-codes the •public•
> SSL/TLS key. This is a significant difference, Jonathan.
>
> --
>
> Jim Manico
>
> @Manicode
>
> (808) 652-3805
>
>
> On Nov 5, 2014, at 11:38 AM, 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/327353e0/attachment-0001.html>


More information about the OWASP-Leaders mailing list