orangeitems’s diary

クラウドで働くエンジニアの日々の感想です。

Peing脆弱性案件に見る初動のまずさ

f:id:orangeitems:20190129010731j:plain

https://peing.net/

 

質問箱Peingに脆弱性が発見されメンテナンス中に

現在、下記ツイートに関連して、質問箱Peingのサービスがメンテナンス中となっています。

 

 

上記の通り、少なくともPeingを連携していたツイッターアカウントに対して、第三者が勝手にツイートできてしまう仕様だったことは間違いないようです。また、だからといってログインできたり、ツイッター連携している他のサービスにログインできたり、ということはない、と否定しています。

しかし、いつからそうなっていたのかはわかりませんし、脆弱性がどんなメカニズムで発生していたのか。また、被害として具体的に何が挙げられるのかを記載していません。

 

初動がまずい(と思う)

ここからは私個人の意見です。

脆弱性が発見されてその後サービスを閉じたのは正しいと思います。

しかし、そこからどんな脆弱性なのかを明確にしていないので、ツイッター上では様々な憶測が飛び交っています。

不安が広がり、とりあえずはPeingのツイッター連携解除しないと、今すぐ危険という噂が広がり、たくさんの人々が解除に動いています。

 

togetter.com

 

できれば、公式自ら情報提供するべきかと思います。

また、被害状況や対策が確定するまでは、利用開始にするべきではないと思います。このままだと1/29 8:00にはメンテナンスが終了してしまいます。まずは、今回の事象・原因・経緯を明らかにした後、安全宣言をしてから正常サービスに戻すべきかと思います。

運営会社のホームページにも、何も情報が記載されておらず、危機管理として初動がまずい、と思います。

 

どうすべきか

私の考える初動対応です。

(1)サービス停止
まずはサービスをすぐ停止する。サービス開始時間はこの時点では未定とする。

(2)第一報
SNS等で、脆弱性が発見されたためサービスを停止したことを知らせる。ただしこの時点では影響が明確ではないため、まずは事実だけの第一報とする。

(3)中間報告
以降、定期的に第二報、第三報等を作成し、わかったことを随時まとめる。特に影響範囲の確定が先。いつからそうだったのか、またどんな情報資産が漏えいした可能性があるか、その件数について確定し、報告する。また、ユーザー側で実施すべき項目がある場合も含めて逐次更新する。

(4)安全宣言
影響範囲が確定し、対策(暫定もしくは恒久)が決定した時点で、安全宣言を出し、サービスの開始を未来にスケジュールして報告する。影響が深刻である場合はサービスを長期中止にし、既存ユーザーについての対応を表明する。

今回は、(1)→(2)まで進んだものの、それ以降の更新(3)がなく、かつ(4)がないまま1/29 8:00にサービス開始すると宣言してしまっているので、初動がまずいと思っています。

ぜひ、上記のセオリーにのっとって、今わかっていることを逐次公開して頂きたいとおもいます。また、サービス再開時刻については、安全宣言を出すまでは未定とすべきかと思います。

去年の段階で100万人ユーザーいるということですので・・影響は小さくありません。

www.itmedia.co.jp

軌道修正を行い、早期にユーザーの不安を解いて頂きたいと思います。

 

追記(2019/1/29 9:45)

ホームページをのぞいてみましたが8:00になってもメンテナンスが明けていませんね。収拾がつくまで一度クローズした方がいいと思うのですが。

 

追記(2019/1/29 12:45)

追加のコメントが出ました。

 

ネットメディアも食いついてきた模様・・。

nlab.itmedia.co.jp

同社は29日に詳細を報告する予定としています。編集部が詳細を問い合わせたところ、公式Twitterに出ていることが全てとの回答でした。

 

これ以上何も公開しないということは、憶測を打ち消すつもりもないということなのでしょうか。

経緯を見守ります。

 

追記(2019/1/29 17:45)

中間報告的な情報がツイッターに更新されました。

 

 

 

 

 

 

 

 冒頭でも書きましたが、サービスを止めた後は、リカバリーより先に影響範囲を確認し速やかに報告したほうが後々楽になります。今回、憶測が乱れ飛んだために結局のところTwitterの連携解除が大変なスピードで進んでいるのではないかと想像します。

また、今回事象が特定されておりますが、ハッシュ化されたパスワードが表示されていたというのが気になるところです。TwitterはBcryptという方式を使ってハッシュ化しています。この仕組みについては、下記文書が詳しいです。

BCrypt(Blowfish暗号)について調べたので文書化してみました - Kamiya::Memo

Blowfish暗号についてざっと書かせていただきましたが、これらはあくまでもパスワードが流出した後に役立つものです。パスワードが漏れないことが一番ではあるのですが、二重三重に保険をかけると言った意味で保存するパスワードが暗号化するのが今は常識になってますね。

ただ、レインボーテーブルには強いBlowfish暗号も、辞書攻撃、ブルートフォースアタックに弱いです。結局パスワードそのものが当たってしまえばソルトもコストもほとんど意味を為さないんですよね…

 パスワードそのものにすぐに復号するのは無理だけれども、パスワードそのものが簡単だった場合には、ハッシュ値の中に書いてあるソルトを使って普通にbcryptでエンコードすると割り出されてしまうと理解しています。

 

※「・ハッシュ化されたパスワード」については、本当は漏えいしていないのではないか、トークンと間違えているのでは?という指摘もあるようで、推移を見守りたいと思います。運営のツイッターに書かれている以上、真偽が不明です。

 

追記(2019/1/29 21:30)

一度サービスインしたものの、再度問題が発見され、再度メンテナンス突入。

 

 

 

最早、公開脆弱性検査のようになってきました。

また、運営企業よりリリースも出ているのですが、

jiraffe.co.jp

 

私の感覚としては、第三者機関によるセキュリティに関する調査が完了するまで、サービスを再開してはいけないと思います。

 

追記(2019/1/30 9:45)

結局、収まるところに収まってきたという印象です。

 

 

 

ちなみに、ハッシュしたパスワードが漏れた件については、Twitterアカウントのパスワードではなく、Peingで独自に設定するパスワードのハッシュだそうです。

 

www.itmedia.co.jp

 このパスワードはPeing特有に設定するものであり、Twitterアカウントのパスワードとは異なる。ソルトはパスワードをハッシュ化する際にパスワードに付加する文字列で、ハッシュ値から元の文字列を推測しづらくするために利用するものだ。

 

今後はサービス開始を急がず、たんたんと調査が進められた後に開始されるでしょう。インシデント発生時の事例として学ぶべき内容の多いシナリオだったと思います。

 

追記(2019/1/31)

サービス再開したとのこと。

 

www.itmedia.co.jp

 

私の感覚よりすごく早い再開なのですが、この判断が正しいのかどうかは、ここから何も見つからないかどうかにかかっていると思います。