クラウドユーザー達は、ハッカーの侵入方法を知ったとき、両手で顔を覆ったかもしれない。
Amazon Web Service (AWS)は、膨大なコンピュータ機能へのアクセスを開発者に提供している。しかし、ハッカーたちはアカウントのハイジャック方法を発見しており、他人のお金でその力を利用して儲けているのだ。
ジョー・モレオのAWSの請求書は毎月約$5程度だ。しかし、先週の木曜日に彼はAWSの認証情報が漏洩したことに気づいた。見知らぬ人物が、彼のAmazonアカウントからコンピュータ機能を拝借していたのだ。それによって彼は東京やサンパウロ、シドニー、シンガポールといった遠方のAmazonデータセンターサーバから$5,300以上の請求を受ける損害を被った。
どうやらビットコインの採掘が行われていたようだ。ビットコイン採掘とは、取引処理と引き替えにデジタル通貨を作成することである。
敵を見つけたと思ったら、それは自分自身だった
攻撃のタイミングから見て、当初モレオはHeartbleedバグが原因だと考えていた。しかし突き止めてみると、それは彼自身の失敗によるものだった。
開発者アカウントのユーザ名とパスワードに加え、AWSはソフトウェアに組み込み易い「アクセスキー」を使用している。まさにそれが問題なのだ。開発者はそれをソフトウェアに組み込み、その中にはGitHubなどの公共ソースコードのリポジトリに彼らが保存しているソフトウェアのコピーも含まれている。
モレオはGitHubのリポジトリにコードをアップデートしていた。不注意なことに、そこには彼のAmazon認証情報が含まれていたのだ。
これは極端な例だと思うかもしれないが、オーストラリアのセキュリティ専門家が先月に実施したGitHubの検索では、約1万件のAWS 認証情報が発見されている。
セキュリティテスト会社Threat Intelligenceの設立者であるタイ・ミラーは、Amazon、Googleのクラウドプラットフォーム、そしてMicrosoft Azureの認証情報が漏洩しているのをGitHubリポジトリで発見したが、最も多かったのがAmazonだという。
「これらの認証情報で、AWSのアカウントが完全に利用できてしまいます。」とミラー氏は述べている。それはハッカーがデータの削除や追加に加え、新しいコンピューティングプロセスを始められることを意味する。ほぼすべてのタスクが実行できるということだ。
Amazonはその問題に気づいているようで、特に開発者に警戒を呼びかけている。警告内容は、開発者がアップロードするコード内の認証情報に関するものなどだ。しかし、この問題を取り締まるためにAmazonが提唱している方法は明確ではない。
Amazonもあなたのサーバも無料
モレオがアカウントの侵害を発見したのは、クレジットカード情報の更新を求めるEメールがAmazonから届いたときのことだった。Appleの元ソフトウェア開発者であるモレオは、ログインしたあとその請求に気づき、すぐにAmazonに問い合わせた。
「お客様のAWS認証情報は漏洩しています」とAmazonの担当者は言った。これらのハッカーたちの共通した目標はビットコイン採掘である。AWSのコンピューティングリソースはあらゆる金儲けを目的とした使用が可能だ。
ソフトウェアコンサルタントのテッド・ハワードはモレオの体験を知って同情した。4月5日に彼自身もAmazonアカウントのハック被害を発見していたのだ。
「すぐにパスワードを変更し、アクセスキーを無効にして、新しいキーを作成しました。」と彼は語った。
ハワードはその侵害は彼の過失だと考えている。彼はGitHubリポジトリを点検して、AWS アクセスキーを含むファイルを危険に晒していたことに気づいた。
「私は自分の愚かさからは逃げられないようです」と彼は言った。しかし、AWS認証情報の意図しない発行は一般的な問題だ。1月に同じ事態がセキュリティ調査員のリッチ・モグルにも起きている。
コンピューティング王国へのキー
ハワードは、Amazonの請求書を処理する必要はあったが、それで問題は解決すると思っていた。
しかし、モレオと話したあとの金曜日、彼は別のセキュリティ侵害をAWSアカウントで発見した。セキュリティ対策をすでに講じていたのにも関わらずだ。
モレオのAmazonの問題が発覚したあと、ハワードがAmazonアカウントに再度ログインすると、13個の新しいEC2 のインスタンスがオレゴン州で開始されていた。彼のアカウントで$6,000の不正請求が発見されたわずか数日後の4月9日だった。
「もちろん私はパスワードを変更し、新しいアクセスキーを作成しました。しかしもう今回は新しいアカウントを作ろうとも思いませんでした」と彼は言った。
新しいアクセスキーは、使用やアッププデート、共有などをまったくしていなかったので、彼は心配になった。
「Heartbleedに関連しているかどうかは誰にも分かりません。私が古いアクセスキーを消滅させたあとでも、彼らがリクエストを承認することはできます。おそらく攻撃者は新しいキーを何らかの方法で知ったのでしょう。私にはまったく検討がつきません」
Amazon: 「こうした問題が頻繁に起きるようになっています」
金曜日の遅くにAmazonがハワードにあることを伝えた。それは彼が認証情報をリセットする前に、ハッカーが「Spot Requests」という機能を彼のアカウントに使った可能性だ。彼がアカウントを確認してみると、それらが多く見つかった。
あなたがAmazonの開発者であれば、使用していないコンピューティングリソースに「Spot Requests」を介して入札することができる。Amazonがあなたの設定した価格を承認すると、自動的に指定されたコンピューティングの使用が開始する。Amazonは、それらのリクエストに関してAmazonのすべての地域を確認する必要性をハワードに伝えた。もし一つを削除したとしても、他の地域のインスタンスには効果がないからだ。
「これの最悪な使用方法は、大量のリクエストを最高額で設定することです。すべての認証情報を変更しても、このリクエストはそのまま残ります。そのため、新しいインスタンスが継続してあらゆる場所に現れます。おそらくこれが私に起きことです。」とハワードは言う。
それはまさにモレオが侵害を発見した日にAmazonの担当者が彼に伝えたことだ。さらにその担当者は、EC2スポットインスタンスを他の地域でも確認するように彼に伝え、ハイエンドインスタンスが見つかることを予言していた。そして、彼は実際にそれを発見した。
ハワードと同様に、モレオはパスワードを変更したが、GitHubからコードを削除する際に細心の注意を払った。それは些細なプロセスではない。リポジトリはバックアップされるので、古いキーをまだ発見できてしまうからだ。
GitHubの親切なチュートリアルでは、リポジトリからファイルを完全に除去し、被害を回避する方法が説明されている。
穴を埋める
最近、Amazonは認証情報の作成方法を変更したと、モレオとハワードは言っている。プログラムがAWSリソースにアクセスできるようにするには、これまでアクセスキーIDとシークレットアクセスキーが必要だった。Amazon が作成する文字列のことだ。以前は、アカウントにログインしてシークレットキーをいつでも取り戻せた。しかし、現在はそれができなくなっている。
「もしシークレットキーを失った場合は、アクセスキーを無効化して、新しいキーを作成しなければなりません」とハワードは言う。
AWS認証情報を管理するAmazonのガイドでは、ルートアカウントのアクセスキーを削除する(または作成しない)ことを推奨している。そして「AWS Identity and Access Management (IAM)」を使用して、AWSリソースと相互動作するアプリケーションのために、一時的なセキュリティ認証情報を作成することを推奨している。また、IAMアクセスキーを管理する方法についても説明している。
「私たちはAWSのセキュリティを重要視しています。私たちは、お客様がAWSサービスを設定し、アプリケーションを開発して頂けるように、多くのリソースやガイドライン、メカニズムを提供することで、セキュリティのベストプラクティスに努めております」とAWSの広報担当者は言う。「私たちは認証情報の漏洩の可能性を発見したら、迅速に影響を受けるお客様に通知し、アクセスキーのセキュリティ対策方法のガイドラインを提供しています」。
しかし、Amazonができることはもっとありそうだ。セキュリティ調査員は簡単にGitHubのなどの公共サイトをスキャンして、アクセスキーを見つけられる。Amazonも同じことを実行し、即座にキーを無効化することで、これらの問題から顧客を救うことはできなかったのだろうか。
自分を守る方法
言うまでもなく、GitHubにコードをアップロードした場合は、不用意に認証情報を提供してハッカーなどがアクセスできるようにしていないかを確認すべきだ。
「多くの開発者が私と同じ失敗を犯しています」とモレオは言う。彼とハワードは次のようにアドバイスしている。
・二要素認証を使用する。これはハワードとモレオのどちらにも役立たなかったが、二種類の認証を介した追加のセキュリティで、Eメールやその他のアカウントのクラウドキーを維持して保護する。これは活用すべきだ。
・クラウドコンピューティング認証情報をハードコードにしてはいけない。Eプライベートソースコードリポジトリを使用していたとしても、それは将来、変更される可能性がある。オープンソースプロジェクトにコードを供給することをもできる。例えば、「コードをすべて点検したあと、認証情報をハードコードにしていたことに気づき、そのコードをコメントアウトしました。そのあと、私は認証情報を初期設定ファイルに移動しましたが、それでも十分ではありません。なぜなら初期設定ファイルは通常コードでリポジトリにチェックインされるからです」とモレオは言う。
・Identity Access Managementを使用する。このAmazonの機能で、権限を制限した個々のアカウントを作成できる。もしS3にデータを保存するアプリケーションを作成したい場合、一つのS3バケットのみがアクセスできるアカウントを作成できる。「もしそのアプリが漏洩したり、認証情報がGitHubにチェックインされたりした場合、その特定のS3バケットだけが露呈します」とハワードは言う。
もしそれでもハッキングが止まらない場合は、起きた出来事に関する情報を収集するべきである。モグルは過去の投稿で、スナップショットを撮影して、ハッキングをフォレンジック分析（データ改ざん等の証拠を残して法的対応に備えること）する方法を説明している。
ハワードが提供する最も重要なアドバイスは?
「Amazon認証情報をソースコードに入れたまま、GitHubなどの公共の場で共有してはいけません！」
当然のことのようだが、何千人もの開発者がこの対策を講じていないことが明らかになっている。
アップデート: 本記事の公開後、ジョー・モレオにAmazonから以下のEメールが届いた。
no-reply-aws@amazon.com からのメール
こんにちはジョセフ様
良いお知らせがあります。一度限りの例外と致しまして、私たちは4月の請求分$5360.23の控除を承認致しました。この控除によって、漏洩したリソースの総額が相殺されます。
想定外の請求を避けるためにAWSの使用状況を定期的に点検してください。「Account Billing consol」eで「Bills」を選択すると、現在と過去の使用状況がサービスと地域別にご確認頂けます。
画像提供：Joe Moreno
※本記事はReadWrite Japanからの転載です。転載元はこちら。
