openSSLの脆弱性で証明書が変わり、APIで四苦八苦した備忘録 (主にwebpay)

phpの下記のようなエラーで悩まされたので、こんな馬鹿なのは自分だけと思いつつも、備忘録も兼ねて掲載。

Network error [errno 35]: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

OpenSSLの脆弱性APIの証明書を再発行したSSLサーバーが多いと思うのだが、自分が使っていたAPIのサーバーも同様に更新していた。
APIはWebPayでライブラリにStripeを使用。

クライアントである自分のサーバーに古い証明書が残っていて、バッティングしてるのかなぁと思って、

$curl = curl_init();
curl_setopt($curl,CURLOPT_SSL_VERIFYPEER,false);

と証明書の検証を行わない設定にしてみたが、改善せず。

色々やってみたのだが、結局下記設定で直った。

$curl = curl_init();
curl_setopt($curl, CURLOPT_SSLVERSION, 3);
curl_setopt($curl, CURLOPT_SSL_CIPHER_LIST, 'SSLv3');

SSLのバージョンと暗号のリストの指定。
今回はライブラリにStripeを使用していたので[ lib/Stripe/ApiRequestor.php ]の172行目辺りに下記設定を追記。

$opts[CURLOPT_SSLVERSION] = 3;
$opts[CURLOPT_SSL_CIPHER_LIST] = 'SSLv3';

今回、WebPayのSSL証明書の更新は4/9なのに、4/11までは普通に使えていた。
なので証明書の更新が原因ではないかも。

SSL通信における脆弱性に対するWebPayの対応

今後狙われると思われる認証失敗時のID、パスワードなど

ある規模のサイト作っている人はみんな思っていると思うが、認証・ログイン失敗時のログの取り扱いは雑になりやすい。

 

ログイン失敗したときに記録するサイトは当然だが結構あって、普通IDと失敗したパスワードがセットで記録される。(IPやそれ以外も)

なぜかって短期間の攻撃の察知、間違えた回数によってアカウントのロックなど良い方向への対策できるから。

また登録されやすい簡単、安易なパスワードを集計し、ユーザーがサイト登録時に登録できない or 警告を出したりする。

 

最近のサイトではパスワードはほぼ salt+スクラッチング+ハッシュ化などされており、平文では保存されない。

データベースが漏洩した時もパスワードを簡単に悪用できないようにだ。

 

ただし、前述の認証失敗した時のパスワードは普通平文で保管される。

そうしないと利用価値が半減するから当然といえば当然だし、これをセキュリティホールと言うのも筋違いだろう。

ただし、このデータは悪意あるものからしたら利用価値が高い。

 

認証・ログイン失敗時 の原因

 

ID、パスワードがNGの場合、理由は色々あると思うが下記のようなものが考えられる。

 

  1. 悪意あるものが攻撃
  2. キーボードの打ち間違い (1文字だけやcapslockがかかっていたなど)
  3. 他のサイトで使っていたID、パスワードの打ち間違い
  4. それ以外

 

1は悪意のあるものは同業者の動向なので、あんまり面白みはないが、2と3は即戦力となりえる。

 

2の場合、

  • 桁数の間違い
  • 隣のキーボードを押してしまった
  • 大文字小文字
  • lやIの読み間違い
  • 法則でパスワード決めている人の法則間違い

などなどありそうだが、バリエーションの全件アタックでもたかが知れてる。

 

3は致命的。即死レベル。

 

 悪い人からしたらデータベースを丸ごと盗むのもありと言えばありだが、当然難しい。

フィッシングサイトを作れば、特定の個人のID、パスワードのリストが何組も手に入る。

 

フィッシングサイトの例

 

ダミーで豪華景品な懸賞サイトなど作って登録させ、ノミネートしたことを忘れた頃に、金額が少ない商品で「当選しました」と通知し、ログインさせる。高額だと怪しい。

最初の1回は無条件でログインに失敗し、何度かID、パスワードを試行させる。

適当なタイミングで成功させ次のステップへ。

 

懸賞の発送先などで個人情報収集し、利用しているサイトなど簡単なアンケートをする。

 

「ありがとうございました。発送は来月下旬です。」

とし、発覚を遅らせる。

最後に「twitter or facebook で当選を自慢する」などのボタンでSNSで発信させ、IDを取得する。

 

リテラシーの高そうな人に向けての例

 

リテラシーの高い人は懸賞サイトなど登録しないだろうけど、WEBサービスβテストの限定招待など、その人の興味ありそうなサービスで、引っかけようと思えば直接狙い撃ちできる。

βテストのトップページなどログイン部分を含めても1時間もかからないし、流行りのサービスを量産させれば引っかかる可能性も上がる。

(最近だと英会話、オンラインストレージ、経理、3Dプリンタ、クレジット決済など。2番煎じぐらいが丁度良い。)

 

私自身、リテラシーが高いとは全く思わないが、IDとパスワードを1対1で保管し、

パスワードの使い回しはしていない。

が、1年以上前かつ第2暗証、秘密の合言葉など駆使されたら、

「第2暗証を登録したか覚えてないけどもしかしてこれかな?」

というような入力はしてしまう。

同様に登録時IDをメールアドレスに限定され、次回ログイン時はメールアドレス以外のIDを要求されると、

IDを登録していなくても試行してしまう可能性がある。

 

とりあえずの結論

 

なにが言いたいかっていうと、サイト作っている人はログイン失敗時のデータを記録するのはしょうが無いとしても、取扱に十分気をつけてねってことで、ユーザーができることは

 

・パスワードを使いまわさない。

・ログイン失敗しても、ID、パスワード変えて試行しない。

 

ってことぐらい。

信用出来ないサイトは登録しないってよく言われるが、現実問題それはほぼ無理かと思う。

 

タイトルに「今後狙われると思われる」って書いたけど、既に存分に悪用されているかも。

 

認証失敗したID、パスワードは記録されていて、高い価値があることを十分理解したほうがいい。(マジで)