unrest.ca

I'm happy to announce that the Open Data Society of BC is putting together a conference to be held in Vancouver on February 19th. The 2013 BC Open Data Summit. There'll be some amazing speakers, and I'm sure it will be quite the event. Tickets are on sale now at http://www.opendatasummit.ca

They say publish or perish, but what happens when publishing puts people's personal information at risk?

Last year I discovered that SSL as it is implemented for server-to-server data transfers in popular software has common, and extremely serious problems. Merchant API's from PayPal, Moneris, Google and others left people's credit card details at risk for interception. I discovered that oauth libraries listed by Twitter were vulnerable -- and found a bunch of other problems that I'm still in disclosure with. It was a big deal, I'd found what computer security folks call a 'class break'.

So I begun a responsible disclosure process. Initiallly I had discovered a vulnerability in a single merchant provider's api and as a good security researcher does, I contacted the vendor -- this quickly went sideways. As a result, I enlisted the help of a local academic and trusted resource of mine, Christopher Parsons. Parsons recommended I get in contact with Tamir Israel, staff lawyer for CIPPIC, and thus begun what was to be (and still is) a nightmarish saga of responsible disclosure and broken cyber security programs.

I've not written this openly about peerjacking before today because this issue is still very much in play, but I feel that because Dan Boneh and his colleagues have published the research that I must respond and set the record straight.

Tamir offered to help me free-of-charge and really went to bat for me, offering legal advice and offering to help with the predicament I was quickly getting myself into. Thanks to Chris and Tamir, we got in contact with the Office of the Privacy Commissioner of Canada to disclose the vulnerability and see if it was within their area of responsibility. After a couple phone meetings, it was determined that because there was no evidence of actual data being stolen via this vulnerability, and with me being unable to provide such evidence without engaging in illegal computer hacking, it was determined it was outside their jurisdiction. The privacy commissioner's process, it seems, is about cleaning up data spills, not preventing them. The file was referred to the CCIRC... The Canadian Cyber Incident Response Centre.

I had already emailed CCIRC, but had received no reply. This is a small agency and while they tell me they that they had received my disclosure, its not clear what they had done prior to the privacy commissioner's office becoming involved. The group seems to work silently behind the scenes -- if there was action, I didn't know about it.... But once the privacy commissioner had referred the file, things changed. Tamir and I began what turned into a weekly discussion with CCIRC about the vulnerability -- it culminated in the Cyber Security Information Notice IN11-003. It was new ground for CCIRC (disclosing new zero-day's is not something they had much, if any, experience with) ... I wanted the agency to name names, but they decided against it. The notice contains only a technical description of the vulnerability, but no context for who is at risk. Mom and Pop shops using PayPal, Moneris or Google would likely never see this notice, nor, if they did, would they understand that their business and customers were at risk. Throughout the back n forth, I was rather miffed about the process, but Tamir rightly pointed out that the disclosure was helpful in that it provided a third party look at the vulnerability and would help confirm what I was saying.

I couldn't live with not disclosing the affected software though, and throughout the process I had found a number of other vendors that were affected -- I'd even found Google Code Search and GitHub Search terms that pointed to a -much larger issue- and found other non-php software that was affected... I had disclosed the affected software that I knew about and the code searches to the CCIRC during the development of the information notice, but they hadn't named names. I'm sure they had their reasons, but I had the public to think about. How were mom and pop merchants going to know to patch? What about their customers credit card details and order information?

I decided to take the list of companies I knew had been notified, and who had had time to resolve the issue, and to disclose about the vulnerability in their software. That resulted in unrest.ca/peerjacking ... but that isn't even close to a complete list, and CCIRC is to my knowledge still working on the issue of the GitHub and Google Code Searches. For my part, after the disclosure I continued to work with PayPal and others to get them patched up. PayPal is still working on this issue in their API's and towards merchant disclosure -- which makes the Boneh et al paper so troubling. I never spelled out how the other PayPal API's were affected because the issue is still being resolved... responsibly.

So that brings me to today. Dan Boneh (a well known academic cryptographer) and a number of colleagues have published "The most dangerous code in the world: validating SSL certificates in non-browser software" ... I had been given a headsup in August about the paper coming out and I reached out to Dan....

[Normally I wouldn't share publicly an email I sent, but since I never got a reply, well, its just my own writing....]

--

Sent on 08/15/2012

Hi Dan,

I was linked this morning to
http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html by
<redacted> this morning. Just wanted to let you know that this appears to
be exactly like my prior published work on peerjacking,
(unrest.ca/peerjacking) and that informs Government of Canada, CCIRC
cybersecurity notice IN11-003.  
http://www.publicsafety.gc.ca/prg/em/ccirc/2011/in11-003-eng.aspx

I am still in responsible disclosure with a number of vendors on this,
including undisclosed vulnerabilities in other PayPal sdks, and non-php
related vulnerabilities, to which I believe you may be making reference.
I have been withholding a full whitepaper on this research while the
industry addresses and resolves these problems. This issue affects a
wide swath of the credit card processing industry and represents a
threat to critical infrastructure. I would appreciate your team not
disclosing the vulnerabilities in specific software before all
responsible disclosure avenues have been properly exhausted.

I am working with CCIRC and others to responsibly disclose this
vulnerability.

--

Kevin McArthur

I never got a reply, and I even blogged about it before it was released, but today I've noticed that the paper has been made available in PDF to the public. I've read it, and I'm cited in it, but I've made it clear previously that peerjacking affects more than PHP applications and that I've purposefully not disclosed the details of the research due to the ongoing responsible disclosure process. To see this research published within the academy and in the face of my plea to respect the responsible disclosure process troubles me.  However, please know that I tried to make sure this vulnerability was resolved before it was widely disclosed.

Welcome to the world of peerjacking. SSL is dead.

I want to thank everyone for their amazing support. I'm happy to announce that I have been elected to a one-year term on the CIRA board. I have lots of great ideas for CIRA and will do what I can to help CIRA be an even more progressive, open and transparent organzation.

If you have any feedback or questions about CIRA, please get in touch. I'm always interested in hearing from members.

This year's CIRA election opens again today and regular readers will know that I am seeking one of the members-slate spots on the board. Nominated by Steve Andersen of OpenMedia.ca fame, I have a long list of reasons for wanting to be on the board, (you can read about them at https://www.kevinforcira.ca ). I believe that CIRA is an important force-for-good within the Canadian Internet ecosystem and that this organization needs to take a more proactive role towards their digital policy objectives.

This year, CIRA saw proposed governance reforms that threatened to take away the members voice and democratic spirit at CIRA. There were also a number of concerning changes in international Internet governance that demand response from Canadian authorities; from the seizure of rojadirecta to the extradition of Richard O'dwyer, the US has adopted the language of the 'foreign rogue site' and seems to be on the path to regulate the world's Internet. This could put Canadians offside for doing little more than sharing the works of Hemmingway which have entered the public domain in Canada, but that still fall under copyright in the USA.

There are also a number of technical challenges, from IPv6 to DNSSEC and even the SSL system. I have a big platform for how to address these challenges, but it all starts with your vote.

In this year's election you get to pick a number of great candidates. I'm voting for Michael Geist and myself ( Kevin McArthur ) on the members slate, and Bill Sandiford and Hank Intven on the committee slate. I believe these folks have a similar public-interest focus for CIRA and that if elected we can make this organization even stronger.

Please head over to http://elections.cira.ca and place your vote.

Christopher Parsons (@caparsons) and I have just published "Understanding the Lawful Access Decryption Requirement" via SSRN

In it we discuss the implications of bill C-30 on encrypted communications, especially those communications featuring systems that feature perfect forward secrecy or client software involved in key generation.

I spent a few hours today working on a piece of open source technology that should help address some of the peerjacking concerns with PHP developers. This tool will help me secure our ecommerce clients, as well as help improve the SSL ecosystem within PHP itself.

So without further introduction, certificate pinning in PHP. A reference design called sslurp (written by Evan Coury (@evandotpro)) and a pin.php pinning script. This builds on the work by Adam Langley and Moxie Marlinspike who did the heavy lifting in developing the pinning algorithm and have also published pinning scripts (written in GO and Python respectively). My PHP contribution to the pinning ecosystem makes it possible to set and verify pinned certs within PHP projects.

#!/usr/bin/php
<?php

/*
Copyright (c) 2012, StormTide Digital Studios Inc.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

    * Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

    * Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in
      the documentation and/or other materials provided with the
      distribution.

   *  Neither the name of StormTide Digital Studios Inc, nor the names 
      of its contributors may be used to endorse or promote products 
      derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
SUCH DAMAGE.
*/

//Version 0.1 Alpha

if(isset($_SERVER['argv']) && is_array($_SERVER['argv']) && !empty($_SERVER['argv'][1])) {
  $cert = $_SERVER['argv'][1];
} else {
  die("Error no cert provided. Usage ./pin.php cert.crt". PHP_EOL);
}

if(is_file($cert) && is_readable($cert)) {
  try {
   $contents = file_get_contents($cert);
   $parsed = openssl_x509_parse($contents);
   $pubkey = openssl_get_publickey($contents);
   $pubkeydetails = openssl_pkey_get_details($pubkey);
   $pubkeypem = $pubkeydetails['key'];
   //Convert PEM to DER before SHA1'ing
   $start = '-----BEGIN PUBLIC KEY-----';
   $end = '-----END PUBLIC KEY-----';
   $pemtrim = substr($pubkeypem, (strpos($pubkeypem, $start)+strlen($start)), (strlen($pubkeypem) - strpos($pubkeypem, $end))*(-1));
   $der = base64_decode($pemtrim);
   //Calculate the SHA1 pin of the Public Key in DER format.
   $pin = sha1($der);
   $base64 = base64_encode(sha1($der,true));
   echo 'Pin for: '. $parsed['name']. PHP_EOL;
   echo 'Pin Hex (SHA1-long): '. $pin. PHP_EOL;
   echo 'Pin Base64 (SHA1-short): '. $base64. PHP_EOL;
   echo 'Pin Chrome format: sha1/'. $base64. PHP_EOL;
 } catch (Exception $e) {
   die('Could not get public key pin');
 }
} else {
  die('Could not read cert');
}

This cli script will generate pins for SSL certificates and the reference design by Evan Coury for validating a pinned connection can be viewed at https://github.com/EvanDotPro/Sslurp/blob/master/src/Sslurp/RootCaBundleBuilder.php#L130

Additionally the sslurp package will, in the future, likely form the basis for bootstrapping a CA bundle into PHP projects requiring secure operation.

I'm running for election to the CIRA Board of Directors again this year. Please support me at https://www.kevinforcira.ca. The Show of Support phase just opened as well, so please find your way over to https://elections.cira.ca/2012/en/support.html to "Show Support"

I just wanted to put up a short update about my PeerJacking research today. The vulnerability I discovered with SSL certificate validation in online commerce applications in July of last year is still in responsible disclosure with a number of software vendors, and I am awaiting the successful mitigation of the vulnerability before releasing the whitepaper describing the scope and impact of these certificate validation failures.

I've been informed by one of these vendors that there is strikingly similar research to be presented at the ACM CCS 2012 conference. I am confused by this as I have not been contacted by these researchers. The researchers published an abstract that revealed a number of the companies affected by PeerJacking, including several that I am currently working with on mitigation of this critical vulnerability. I've attempted to contact the academics involved, but have not seen any reply yet, though, the abstract in question appears to have been removed from the web for the time being. 

PeerJacking (programming failure to verify peer certificates) affects nearly all major programming languages and is depressingly common. It is deployed widely throughout commercial server-to-server API's from hundreds of distinct vendors. It is the breadth of the vulnerability and the sheer number of affected vendors that makes responsible disclosure of this vulnerability so complicated and why 13 months later I am still largely limited in what I can say publicly about this issue.

As before, please contact the Canadian Cyber Incident Response Centre for advice. They are the agency handling the responsible disclosure, notification and mitigation of this vulnerability affecting critical infrastructure.

See also (previous posts on this topic):
PeerJacking - SSL Ecosystem Attacks Against Online Commerce
Credit Card System Update (IN11-003)
Credit Card System Vulnerability
Update on Credit Card System Vulnerability.

Update on CIRA governance.

Wednesday CIRA (The Canadian Internet Registration Authority) announced that they were reversing course on their plans to overhaul the governance structure of the not for profit organization and would instead only make by-law changes required to conform to the new NFP regulations.

In a post by Paul Andersen, which you can read here ( http://blog.cira.ca/2012/08/guest-post-by-paul-andersen-results-of-ciras-outreach-on-governance/ ), Paul explains how CIRA came to this decision and some of the issues they have had with engaging the member community on consultations around governance.

Overall I'm pleased with the outcome, the members slate will be retained, and CIRA will continue to operate as a democratic internet governance organization for the time being. The size of the board will be maintained and many of the other more minor concerns have been addressed as well.

I'm also pleased to see that the CIRA board has heard the members, even if the response group was small, and that they have shown that they are willing to seriously consider member feedback and even reverse course when they get it wrong. This really underscores how the CIRA governance process is working well today, and we should all thank the board for their continued service and most importantly for being willing to reconsider actions in consultation with members.

I'd also like to thank Paul Andersen for putting together a great blog post on the topic as it signals a distinct shift from prior member engagement, and really helps the community understand the inner workings of this important organization better.

I am also happy to announce that I will be running in the CIRA board of directors election again this year. I will be competing for one of two members-slate positions that will be available through this year's election cycle.

I plan to run on substantially the same platform as last year, and will be looking for your support again this year. I will be announcing the launch of my campaign in the coming days.