TeamTNTが不正デプロイで使用するDockerHub認証情報を確認｜トレンドマイクロ

トレンドマイクロでは、クラウドセキュリティ上の脅威となりうる脆弱性や設定不備を抱えたプラットフォーム、またはサービスへの攻撃状況を把握するため、攻撃者をおびき寄せる「ハニーポット」を設置し、継続的に調査を行っています。こうしたハニーポットの中には、クラウドサービスのプロバイダとユーザ双方の視点からの脅威分析のために、Docker REST APIハニーポットがあります。このREST APIハニーポットに記録された情報を解析したところ、攻撃者は、Dockerで動くマルウェアの展開、およびそのTTPs（Tactics：戦略、Techniques：テクニック、Procedures：プロシージャ）の実現手段として、コンテナレジストリを使用していることが判明しました。

今回ハニーポットへの攻撃を試みたのは攻撃グループ「TeamTNT」であり、その際に当該グループが使用するDockerHubアカウントの認証情報が少なくとも2件、ハニーポット側に記録されていました。攻撃者は、自身で管理するDockerHubレジストリのアカウントにログインし、ログアウトの実行を忘れたままハニーポットへの攻撃を開始したと推定されます。後述するように、手動でログアウトをしない限り、アカウントの認証情報はヘッダー情報「X-Registry-Auth」の値としてサーバ側に送信され「流出」することになります。

ハニーポット上に記録された1件目のアカウントはalpineos（プル回数150,000）、2件目はsandeep078（プル回数200）でした。１件目のアカウント「alpineos」は、2021年の9月中旬から10月初旬にかけて、ハニーポットに対する3度に渡る攻撃において使用されたことも確認できました。攻撃元のデプロイIPアドレスを追跡したところ、該当地域はドイツであることが分かりました。トレンドマイクロでは、既にこれらのTeamTNTが使用するアカウント情報をDockerに報告しています。

上述のDockerHubアカウントは、下記を含む不正なコンテナイメージのデプロイに、頻繁に利用されました。

ルートキット
Dockerのコンテナエスケープ用ツール
Monero用の暗号資産マイナー「XMRig」
認証情報窃取ツール
マルウェア「Kinsing」
Kubernetesの攻撃用ツール

2021年7月、トレンドマイクロはTeamTNTの攻撃活動について調査を行い、当該グループが不正侵入の経路としてDocker APIを使用した証跡を見つけました。この調査において、攻撃による侵害を受けた、または不正なDockerHubアカウントが計26件見つかりました。今回は新たに2件のアカウントを発見しましたが、分析価値がより高いのは150,000回以上に渡って不正なコンテナイメージをホストした「alpineos」の方でしょう。

コンテナレジストリとDockerデーモン

Dockerはコンテナサービスのプラットフォームであり、一度プログラムを書けばどこでも実行できる仕組み（WORA：Write-Once-Run-Anywhere）を開発者に提供します。簡便な利用法に加え、プログラムの作成やアプリケーションのデプロイをスムーズに行える利点も相まって、開発者の間で高い評判を得ています。さらに重要なこととして、Dockerはどのプラットフォーム上でも動作します。

GitHubなどのリポジトリがコードやプログラムの格納、配布に使用されるのと同様、コンテナレジストリはコンテナイメージの格納、配布に使用されます。適切な権限を持つユーザであれば、イメージを「プル」して、そのイメージをベースとするコンテナを作成し、アプリケーションをデプロイするという一連の操作を容易に実行することが可能です。コンテナイメージをホストするコンテナレジストリは数多く存在しますが、代表的なものとしてDockerHub、Amazon Elastic Container Registry（ECR）、Alibaba Container Registryが挙げられます。

コンテナ作成時のデフォルト動作では、「コンテナデーモン」がコンテナレジストリ内から対象イメージを検索します。今回の分析ではコンテナレジストリとしてDockerHubを用います。

図1：Dockerデーモン（dockerd）が「Hello World」のイメージをDocker Hubからプルする例

上図に示される通り、レジストリを指定しない場合はDockerHubがデフォルトで選択されます。Dockerでは、リモートホスト側にコンテナを作成することが可能です。この機能を使用するには、リモートホスト側で稼働するdockerデーモンがTCPによるサービス呼び出し（デフォルトポート番号は2375）を受け入れるように設定されている必要があります。この機能によって、curl、wget、docker-cliなどの外部接続ツールを介してイメージやコンテナ、ネットワーク、ボリュームなどのDocker用サービスにアクセスすることも可能になり、リモートでの開発作業やデプロイ作業がより一層容易なものとなります。

Dockerコンテナ作成用のREST API

DockerのREST APIを使用して、リモートサーバ「172[.]31[.]42[.]11」に、alpineのイメージ（Alpine Linux：musl libcライブラリとBusyBoxユーティリティで構成されたLinuxのディストリビューション）をベースにしたコンテナを新規作成するシナリオについて考えます。このリモートサーバは、dockerdのサービスをTCPポート2375で公開しているものとします。

ネットワークのトラフィック情報を見ると、リモートホスト上にコンテナの作成を依頼する際には、下記の手順が取られることが分かります。

クライアントからサーバに、アクセス可能であるかを確認するためのpingデータが送信される（図3のパケット2298）
サーバからクライアントに、アクセス可能であることを示すステータスコード200が返却される（パケット2300）
クライアントからサーバに、「alpine」という名前のイメージをベースとしたコンテナの作成依頼データが送信される（パケット2302）
サーバのローカル環境内に「alpine」の名前を持つイメージが存在しない場合、ステータスコード404がクライアントに返却される（パケット2304）
クライアントがサーバの情報を取得するため、エンドポイント「/バージョン番号/info」にアクセス（パケット2306）
サーバからクライアントに、システム全体の情報が返却される（パケット2308）

図4：alpineのイメージがサーバのローカル環境内で見つからないため、ステータスコード404を返却

クライアントからサーバに、alpine用イメージの作成依頼データが送信される；タグ指定がない場合は「latest」が選択される
サーバからクライアントに、DockerHubからのalpine用イメージのダウンロード状況が送信される

クライアントからサーバに、ダウンロード済みのalpineイメージに基づくコンテナの作成依頼データを送信

図6のヘッダー情報「X-Registry-Auth」をBase64でデコードすると、括弧のみの文字列（{}）であることが分かります。下図に示すDockerのドキュメントによると、「POST /images/名前/push」のようにレジストリとの通信が発生するエンドポイントを使用する際には、Base64でエンコードした認証情報をX-Registry-Authに格納してサーバ側に送信する必要があります。

上述のシナリオにおいて、alpineベースのコンテナ作成をサーバに依頼したクライアントは、DockerHubのレジストリにログインしていませんでした。このため、X-Registry-Auth の値をBase64でデコードした結果は、括弧のみ（{}）でした。ユーザがレジストリにログインして、独自のリポジトリを使用して作業する必要がある場合は、「docker login」を使用します。

ここで、正規ユーザが「docker login」を使用してアカウント「satoshiav0cad0」にログインした上で、上記の手順を繰り返すシナリオを考えます。この場合、Base64でエンコードされた認証情報がヘッダー情報「X-Registry-Auth」に格納されます。

上図が、DockerHubのユーザ「satoshiav0cad0」に紐づく認証情報です。サーバにコンテナ作成を依頼するクライアント側が事前にDockerHubのコンテナレジストリにログインしていた場合にのみ、認証情報がヘッダー「X-Registry-Auth」に格納されます。

認証情報流出のシナリオ

今回、攻撃者のミスにより、使用する認証情報がハニーポット側に「流出」しました。しかし、正規のユースケースとして、ユーザが自身のDockerHubレジストリにログインして、プライベートなリポジトリのイメージをベースにコンテナを作成したい場合もあるでしょう。そのユーザが「docker logout」の操作を行うことなく、信頼性の確認できないリモートホスト上にコンテナ作成を依頼すると、Base64でエンコードしただけのユーザ名やパスワードも送信されることになり、セキュリティリスクに繋がります。このリスクの第一のシナリオとして、被害者がDockerHubレジストリにログインしている状況を想定します。ここで攻撃者は、被害者が所有する仮想マシン（VM）を何らかの方法で不正に操作して、当該の攻撃グループが管理するリモートサーバ宛てにコンテナの作成を依頼します。先に述べた通り、コンテナ作成に使用するイメージが存在しない場合、DockerHubからダウンロードします。この際、Base64でエンコードした被害者の認証情報が、ヘッダー情報「X-Registry-Auth」に格納されてリモートサーバ側に流出します。

図11：第一シナリオ；DockerHubからイメージをダウンロードする際にBase64でエンコードされた認証情報が流出

認証情報が窃取されると、そこからさらに下記の情報が探られ、攻撃活動に転用される可能性があります。

紐付くメールアドレス、使い回されている認証情報：サイバー犯罪者は、異なるプラットフォーム間で同じパスワードが使い回されているかどうか探ろうとする
プライベートなリポジトリやイメージ：こうしたデータの内部にはAPI鍵などの機密情報が含まれており、バックドアを使ってプライベートなイメージが書き換えられる可能性がある
アクセストークン：アカウントへのアクセスを永続化するために不正使用される
開発ツール：専門機能（Teams、Organization、ビルドパイプラインなど）によってDockerベースのビルドパイプラインが不正に操作され、サプライチェーン攻撃に発展する可能性がある

逆の視点として、サイバー犯罪者が自身のDockerHubレジストリにログインした状態で、その認証情報を誤って流出させるシナリオも考えられます。正規ユーザが攻撃者の認証情報を気にかけるようなことは通常ありませんが、セキュリティ調査の観点では、ログアウトをしなかった攻撃者の追跡、確保に繋がるという点で重要な意味を持ちます。実際、今回の事例で挙げた攻撃者は、TCPでdockerdを公開しているハニーポット上にコンテナを作成しようとしました。このハニーポットでは、パケットキャプチャ「tcpdump」によってネットワークのトラフィック情報が記録されているため、そこからBase64でエンコードされた攻撃者の認証情報を取り出すことも可能です。

結論

開発者はコンテナを利用することで、開発やデプロイのワークフローを効率化して生産性を高めます。一方、サイバー犯罪者はコンテナなどのコンポーネントに潜む小さな設定不備を利用することで、攻撃の手段を確立します。設定不備を突いてサーバ内部に侵入した攻撃者は、不正な暗号資産マイニングツールのインストール、秘密鍵や認証情報の窃取をはじめとする攻撃的活動を行う他、最悪の場合は当該サーバを支配してマルウェアボットネットの一部に取り込む可能性もあります。不正利用が可能なコンポーネントやアカウントが存在する限り、TeamTNTをはじめとするサイバー犯罪者による活動がすぐに止むことはないでしょう。

今回の調査でTeamTNTが使用するアカウント情報が特定されたのは、下記3つの要因が重なった結果と考えられます。

攻撃者がアカウント「alpineos」の認証情報を使用してDockerHubにログインした
攻撃者自身の端末が感染していて、かつ認証情報ヘルパーを使用していなかった
攻撃者が当該のDockerHubアカウントからログアウトすることなく、Docker用REST APIを公開しているサーバに対する攻撃を実行した

今回のように認証情報が流出したコンテナレジストリ用アカウントは計30個あり、その全てがDockerHubまたはAlibaba Cloudのいずれかに該当するものでした。トレンドマイクロではこれらの情報を取得し、上述のTeamTNTに不正使用されたと考えられる認証情報にアクセスすることも可能でしたが、こうした情報に対する不正アクセスは行いませんでした。問題となったアカウントについてはDockerに報告済みであり、対策に関する検討を進めています。

Dockerをはじめとする開発者向けのツールが攻撃グループによって不正利用される状況を踏まえると、企業や組織のセキュリティチームでは、開発段階からのセキュリティ対策に目を向けることが特に重要です。使用する環境に応じた脅威モデルを分析するとともに、認証情報の利用やアクセスに関するポリシーを規定することを推奨します。こうして確立した脅威モデルやポリシーは、開発者向けのセキュリティ教育において、何がどのような問題を引き起こすのかを論じる際にも役立つでしょう。脅威を軽減するために企業や組織、開発チームで実施できる対策として、下記が挙げられます。

DockerデーモンのREST APIを使用してリモートホスト上にコンテナを作成する場合、イメージの取得元のコンテナレジストリを指定すると、DockerHubの認証情報が送信される点に注意する。また、リモートホストの信頼性が確認できない限り、そのようなことを行うべきではない。
ユーザの認証情報を標的とする不正なオープンソースパッケージが増加していることを踏まえ、環境変数など安全とは言えない場所に認証情報を保存することは避ける。代わりに、認証情報ストレージや認証情報ヘルパーなどの専用ツールを使用する。
DockerデーモンのREST APIをインターネット上に公開する必要がある場合は、TLS（Transport Layer Security）による暗号化通信プロトコルを使用する。これにより、中間者攻撃（MiTM：Man-in-The-Middle）によって認証情報が窃取されるような自体を回避できる。

本調査に関するより詳細情報は、2022年の9月21日から24日にかけて開催される「c0c0n XV Hacking and Cyber Security Conference」で発表されました。

侵入の痕跡（Indicators of Compromise、IoC）

侵入の痕跡（IoC）については、過去事例に関するブログエントリ（1件目、2件目）をご確認ください。

参考記事：

Security Breaks: TeamTNT’s DockerHub Credentials Leak
By: Nitesh Surana

翻訳：清水浩平（Core Technology Marketing, Trend Micro™ Research）

タグ

TeamTNTが不正デプロイで使用するDockerHub認証情報を確認

執筆者

リソース

サポート

会社概要

リソース

サポート

会社概要

The Americas

Asia Pacific

Europe, Middle East & Africa