[Owasp-leaders] OWASP Mobile Top Ten 2014 - M10 Datapoints
Jim Manico
jim.manico at owasp.org
Wed Nov 5 10:37:37 UTC 2014
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] *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
> <mailto: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 <tel:%28808%29%20652-3805>
>
>
> On Nov 5, 2014, at 11:38 AM, Jonathan Carter
> <jonathan.carter at owasp.org <mailto: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
> <mailto: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
> <mailto: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/43d2a2b7/attachment.html>
More information about the OWASP-Leaders
mailing list