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

Jim Manico jim.manico at owasp.org
Wed Nov 5 11:48:01 UTC 2014

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
(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,


*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 :


 On 11/5/14 5:28 PM, Erwin Geirnaert wrote:


*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


(808) 652-3805

On Nov 5, 2014, at 11:38 AM, Jonathan Carter <jonathan.carter at owasp.org>

 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

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

   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

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.)


OWASP-Leaders mailing list
OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20141105/07e36990/attachment.html>

More information about the OWASP-Leaders mailing list