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

Jonathan Carter jonathan.carter at owasp.org
Wed Nov 5 12:01:45 UTC 2014


I think you've made this personal by trying to impose your view of the
world on a technical space you really don't specialize in. My 2 cents...

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

> I politely suggest you stick to the debate and move this to the mobile
> list. No need to make this personal, it's not my intention, Jonathan, and I
> hope it's not yours either.
>
> --
> Jim Manico
> @Manicode
> (808) 652-3805
>
> On Nov 5, 2014, at 7:55 PM, Jonathan Carter <jonathan.carter at owasp.org>
> wrote:
>
> With all due respect, you are a web guy and not a mobile guy.
>
> On Wed, Nov 5, 2014 at 3:53 AM, Jim Manico <jim.manico at owasp.org> wrote:
>
>> So an attacker who is savvy enough to distribute custom modified mobile
>> apps and who knows how to surgically identify pinned certs and change them
>> can't get around obfuscation? I disagree with this threat model, I submit
>> with respect.
>>
>> --
>> Jim Manico
>> @Manicode
>> (808) 652-3805
>>
>> On Nov 5, 2014, at 7:50 PM, 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/12e61e12/attachment.html>


More information about the OWASP-Leaders mailing list