<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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....<br>
    <br>
    - Jim<br>
    <br>
    <div class="moz-cite-prefix">On 11/5/14 4:38 PM, Jonathan Carter
      wrote:<br>
    </div>
    <blockquote
cite="mid:CACgV-55PRRufv+4ztZSkcwoGk+RhJ6TF7kjkQyFQAO64q5EJ4w@mail.gmail.com"
      type="cite">
      <div dir="ltr">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.<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Tue, Nov 4, 2014 at 11:41 PM, Jim
          Manico <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:jim.manico@owasp.org" target="_blank">jim.manico@owasp.org</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="auto">
              <div>Certificate pinning does hard-code •secrets•, it
                hard-codes the •public• SSL/TLS key. This is a
                significant difference, Jonathan.<br>
                <br>
                <div>--</div>
                <div>Jim Manico</div>
                <div>@Manicode</div>
                <div><a moz-do-not-send="true"
                    href="tel:%28808%29%20652-3805" value="+18086523805"
                    target="_blank">(808) 652-3805</a></div>
              </div>
              <div>
                <div class="h5">
                  <div><br>
                    On Nov 5, 2014, at 11:38 AM, Jonathan Carter <<a
                      moz-do-not-send="true"
                      href="mailto:jonathan.carter@owasp.org"
                      target="_blank">jonathan.carter@owasp.org</a>>
                    wrote:<br>
                    <br>
                  </div>
                  <blockquote type="cite">
                    <div>
                      <div dir="ltr">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.<br>
                        <div class="gmail_extra"><br>
                          <div class="gmail_quote">On Tue, Nov 4, 2014
                            at 7:12 PM, Tim <span dir="ltr"><<a
                                moz-do-not-send="true"
                                href="mailto:tim.morgan@owasp.org"
                                target="_blank">tim.morgan@owasp.org</a>></span>
                            wrote:<br>
                            <blockquote class="gmail_quote"
                              style="margin:0 0 0 .8ex;border-left:1px
                              #ccc solid;padding-left:1ex"><br>
                              Hi Leaders,<br>
                              <br>
                              I have brought up my concerns about M10
                              before and I have done a fair<br>
                              bit of thinking about this since then.  I
                              think it would be useful to<br>
                              re-frame the discussion with some more
                              subtle distinctions:<br>
                              <br>
                              <br>
                              0. Are all software security risks also
                              considered business risks?<br>
                              <br>
                                 Yes, I would say so.  It is hard to
                              find a computer security risk<br>
                                 that doesn't pose some kind of business
                              risk.<br>
                              <br>
                              <br>
                              1. Are all business risks considered
                              security risks?<br>
                              <br>
                                 No, I definitely don't think so.  There
                              are plenty of things<br>
                                 outside of the realm of software
                              security that are very real<br>
                                 business risks (e.g. employees running
                              over a business partner in<br>
                                 the parking lot by accident).<br>
                              <br>
                              <br>
                              2. Is binary modification/repackaging a
                              real business risk to<br>
                                 intellectual property?<br>
                              <br>
                                 Yes!  It is happening already.  An
                              attacker could repackage your<br>
                                 app, redistribute, and reap benefits
                              from app stores based on your<br>
                                 hard work.<br>
                              <br>
                              <br>
                              3. How is mobile reverse engineering
                              and/or repackaging a security<br>
                                 risk?<br>
                              <br>
                                 Yes, specifically:<br>
                              <br>
                                 A) Reverse engineering can expose
                              crypto keys and any other secrets<br>
                                    that are foolishly embedded in the
                              app.<br>
                              <br>
                                 B) Repackaging can be used to try and
                              fool users into installing<br>
                                    the wrong version of an application
                              which has malicious intent.<br>
                                    Very similar to phishing.<br>
                              <br>
                              <br>
                              4. Does mobile app
                              obfuscation/monitoring/anti-reverse
                              engineering<br>
                                 technology help solve a *business*
                              risk?<br>
                              <br>
                                 Yes, in that it raises the cost of
                              reusing the compiled version of<br>
                                 the software.  Raise the cost enough,
                              and the attacker might as<br>
                                 well write their own app.  Even if you
                              don't raise the cost *that*<br>
                                 high, you reduce the number of people
                              willing to target your app<br>
                                 specifically.<br>
                              <br>
                              <br>
                              5. Does mobile app
                              obfuscation/monitoring/anti-reverse
                              engineering<br>
                                 technology help solve a *security*
                              risk?<br>
                              <br>
                                 No, I don't think so.<br>
                              <br>
                                 Regarding (3A)-- If crypto
                              keys/credentials/etc are valuable, it<br>
                                 doesn't take a whole lot of effort
                              decode an obfuscated binary to<br>
                                 get that them.  Definitely worth the
                              minimal effort.<br>
                              <br>
                                 Regarding (3B)-- If cloning apps like
                              this is effective against<br>
                                 users, then it's just as easy to copy
                              the images from the company's<br>
                                 website, slap it on a "hello world"
                              app, add a login form, and<br>
                                 poof: you have users' credentials.  You
                              don't need to clone a whole<br>
                                 app to fool users.<br>
                              <br>
                              <br>
                              <br>
                              <br>
                              I think many folks on each side of the
                              discussion are correct in what<br>
                              they are saying, but they are talking
                              about different things.  Look at<br>
                              the issue with a slightly higher
                              resolution, particularly in the<br>
                              context of what attacks are actually
                              applicable, and it all becomes<br>
                              much more clear:  Remove M10.  (After all,
                              OWASP is primarily about<br>
                              computer security, not digital rights
                              management.)<br>
                              <br>
                              <br>
                              Cheers,<br>
                              tim<br>
                            </blockquote>
                          </div>
                          <br>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </div>
              </div>
              <span class="">
                <blockquote type="cite">
                  <div><span>_______________________________________________</span><br>
                    <span>OWASP-Leaders mailing list</span><br>
                    <span><a moz-do-not-send="true"
                        href="mailto:OWASP-Leaders@lists.owasp.org"
                        target="_blank">OWASP-Leaders@lists.owasp.org</a></span><br>
                    <span><a moz-do-not-send="true"
                        href="https://lists.owasp.org/mailman/listinfo/owasp-leaders"
                        target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a></span><br>
                  </div>
                </blockquote>
              </span></div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>