orangeitems’s diary

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

GitHubで継続的に発生している大規模インシデント | 便利と危険は裏返し

f:id:orangeitems:20180830161022j:plain

 

GitHubから情報漏えい

中国の大規模な情報漏えいのお話です。


www.itmedia.co.jp

技術情報サイトのBleeping Computerは8月28日、中国の大手ホテルチェーンHuazhu Hotels Group(華住酒店集団)の利用客1億3000万人あまりの個人情報が、中国のダークWebフォーラムで売りに出されていると伝えた。

(中略)

Bleeping Computerは、中国のセキュリティ企業Zibaoが地元メディアに語った内容を引用して、Huazhuの開発チームが誤ってデータベースのコピーをGitHubアカウントにアップロードしたことが原因だったようだと伝えている。

 

GitHubはマイクロソフトが買収することが決まっている、ソフトウェア開発者向けのソースコードホスティング基盤です。ソースコード管理ソフトウェアであるGitをインターネットでサービスとして提供しているのが特徴です。

無料版を使う場合は、ソースコードが公開され、第三者が参照することができます。人気のプロジェクトはスターをもらうことができ、オープンソースソフトウェアとして世界の人々が便利に使うことができます。

 

employment.en-japan.com

 

こうやって見ると、ソースコードだけではなく、有用なサイトや動画のリンクやドキュメントなど幅広く利用されていることがわかります。

企業のソフトウェア開発など、ソースコードを非公開で管理したい場合は、有料版に移行して使うというサービスです。

 

GitHubからの漏えい事件

便利なGitHubなのですが、使い方を間違えるととんでもない状況となります。

 

AWSにアクセスするアクセスキーペアを抜かれちゃう問題

アプリケーションにて、AWSリソースにAPIでアクセスするような処理をソースコードに書いたとします。もちろん、アクセスキー ID とシークレットアクセスキーが埋め込んであります。GitHubにアップロードすると何が起こるでしょうか。

なんと、常にGitHubをクロールする悪者がいて、アクセスキーを入手されてしまうのですね。

実際に試された方がいらっしゃいますのでご参考まで。

 

qiita.com

GitHub にはアクセスキーを検索するBOTが常に動いていて、公開するとすぐに抜かれて不正利用される 的なコメントがつくのを何度か目にしたのですが、
本当にそんな BOT が動いているの?
どのくらいの時間でキーを抜かれて、不正利用が始まるの?
というのが気になったので、検証してみました。

 

結局のところ、認証を埋め込んでいるようなソースコードを公開するなよ、というのが本筋なのですが人間がやることなので怖い話だなと思いました。

AWS自身がクロールしていることも含めて、人間自身が脆弱ですね。

 

Appleですらやらかした件

Appleと言えば、優秀な開発者集団のように思いがちですが、iOS(iPhoneのOS)の一部ソースコードをGitHubに公開しちゃったという話です。

 

www.itmedia.co.jp

米AppleのiOSのソースコードの一部が流出し、何者かがGitHubで公開していたことが分かった。問題のコードは、その後Appleの要請に基づいて削除されたが、脱獄(Jailbreak)などに利用される可能性も指摘されている。

 

優秀かどうかに関わらず、人間には、勘違い、思い込み、不調など、脆弱性が埋め込まれていて、それが発現するとインシデントとなってしまうのは法則のようです。気を付ければ大丈夫、と思っている時点で、気を付けなければこのような大問題になってしまいます。フェールセーフという言葉がありますが、失敗しても安全に倒れるようにしないとこのGitHubというサービスは危険だなと思った次第です。

 

非公開がハッキングされたウーバー

非公開なら安全だよね、というのもまた思い込みですね。

 

www.bbc.com

ウーバーはハッキングの具体的な詳細について確認していないが、ブルームバーグの報道によると、2人のハッカーが開発者向けのオンラインサービス「GitHub」の非公開部分に侵入した。
ハッカーはそこから、企業がデータ保管に使うクラウドサービスを提供するアマゾン・ウェブ・サービス(AWS)のウーバーのログイン情報を見つけたとみられている。

 

非公開というのは、裏を返せば何らかの認証情報を持ってアクセスできるということになります。その認証の強度や、破られた時のリスクを把握しコントロールしないと、とんでもない状況に陥ると言えます。

 

オープンソースが改ざんされたという話

例がたくさんあるので、この際挙げておきます。

 

nanashi0x.hatenablog.com

6/28(木)、Gentoo Linuxが所有するGitHubアカウントが悪意を持つ何者かに乗っ取られた事がわかった。
Gentoo LinuxディストリビューションのGitHubアカウントへのアクセスを管理していた個人が元のソースコードを悪意のあるコードに置き換えたのだ。

 

あまり日本ではなじみのないLinuxディストリビューションであるGentoo Linuxですが、このGitHub上のオープンソースを乗っ取られて、マルウェアを仕込まれてしまったという件です。

Linuxベースのデバイスやシステムを作る時に、GitHubからインストーラーをダウンロードしインストールしますが、この時点でマルウェアが混入されるとユーザーはたまったものではありません。個人情報を不意にアップロードされたり、システムが急停止するなど影響は甚大です。

 

なお、対策はもう取られているそうです。

nanashi0x.hatenablog.com

Gentooが攻撃を受けて取った再発防止策は以下の通りです。
・定期的なGitHub Organizationのバックアップ
・2段階認証のデフォルト化
・インシデント対応計画の作成
・未使用アカウントの削除
・高い権限を持つユーザを減らす
・ログインの監視
・パスワードマネージャーの使用
・ハードウェアベースの2段階認証

 

生産性の前に、リスク評価を

世の中が、生産性重視に走っていることは間違いありません。

でも、リスクを無視してまで優先する生産性なんてありはしないのです。リスクを一生懸命考えて、考え抜いて、それでコントロールするのであれば一つ、アセスメントの方法としてはふさわしいと思います。また、生産性を犠牲にしてでも使わないというのも立派なアセスメントです。

便利なツールが出て、それをどんどん使って生産性向上をしたら、先端的でかっこいい、という短絡的なビジョンで突っ走る技術記事も多数散見されます。

おかげで、何億人の人々の情報が晒されてしまうということが、日常茶飯事になっています。

過去の慣習にとらわれることは合ってはいけないですが、過去の慣習だからといって価値を低く見積もるのも考え物だと思います。何を採用するにしても、リスクの評価は一番にすべきだと思います。

GitHubにしても、「こうすれば防げた」という対策がたくさんあるのですが、そもそもそのような対策をデフォルトとしそれ以外の設定では利用できないようにするべきです。今日にいたっても1億3000万人の情報漏えいが起こっている事件を聞くと、私ならリスクがまだ高いと判断しますね。個人的には、自分でサーバーを借りてGitを自前ホスティングしたほうがまだ安全かと思います。

 

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉