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

Wed Nov 5 11:54:49 UTC 2014

I suggest we move this to the mobile list and stop spamming leaders. :)

Aloha,
--
Jim Manico
@Manicode
(808) 652-3805

On Nov 5, 2014, at 7:52 PM, Jonathan Carter <jonathan.carter at owasp.org>
wrote:

And certificate pinning has more to do with content inspection of the
certificate issued by the server. So, you don't have to forge a certificate
within the client. You just have to modify the values of the properties you
are inspecting and then compare that against the attacker's destination.
It's a very real and legitimate mobile attack vector.

On Wed, Nov 5, 2014 at 3:50 AM, Jonathan Carter <jonathan.carter at owasp.org>
wrote:

> The attacker is downloading the app, making the mods to their own version
> of the app, and then distributing that to the victim.
>
> On Wed, Nov 5, 2014 at 3:48 AM, Jim Manico <jim.manico at owasp.org> wrote:
>
>> What I'm hearing is....
>>
>> 1) You can modify •your own• mobile binary
>> 2) Change •your own• pinned cert
>> 3) And then man in the middle yourself (by making a forged certificate
>> signed by a real authority?)
>>
>> I do not see this as a real risk.
>>
>> --
>> Jim Manico
>> @Manicode
>> (808) 652-3805
>>
>> On Nov 5, 2014, at 7:41 PM, Erwin Geirnaert <
>> erwin.geirnaert at zionsecurity.com> wrote:
>>
>>  Hi Jim,
>>
>>
>>
>> If we can execute a man-in-the-middle during black-box mobile app
>> security testing, we often find more issues and attack vectors.
>>
>> Man-in-the-middle is for mobile a real problem.
>>
>>
>>
>> Best regards,
>>
>>
>>
>> Erwin
>>
>>
>>
>> *From:* Jim Manico [mailto:jim.manico at owasp.org <jim.manico at owasp.org>]
>> *Sent:* 05 November 2014 11:38
>> *To:* Erwin Geirnaert; Jonathan Carter
>> *Cc:* OWASP Leaders
>> *Subject:* Re: [Owasp-leaders] OWASP Mobile Top Ten 2014 - M10 Datapoints
>>
>>
>>
>> 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/79576dd0/attachment.html>