Uber に続き Rockstar Games でもソーシャルエンジニアリングによる被害が発生

** 本記事は、Uber, Rockstar fall to social engineering attacks; and you? の翻訳です。最新の情報は英語記事をご覧ください。**

「セキュリティは目的地ではなくプロセスである」とセキュリティの専門家はしばしば口にします。最近の Uber と Rockstar Games に対する攻撃はまさにその一例です。詳細はまだ明らかになっていませんが、起こった情報漏洩を分析して、自社の情報セキュリティ対策に役立てることはできます。

2021 年 7 月の Electronic Arts に対する Lapsus$ 攻撃と同様に、攻撃者は窃取された認証情報を初期アクセスブローカー (IAB) から購入したようです。IAB は通常、電子メールによるフィッシング攻撃や、情報窃取型トロイの木馬をさまざまな方法でデバイスに感染させるなどの手法で、認証情報を大量に収集します。IAB はトロイの木馬を使って、被害者の PC に保存されているパスワードやセッション Cookie、時には暗号通貨のウォレットに至るまでさまざまな情報を収集し、その多くをダークウェブで売りに出します。

Uber は、Uber の内部ネットワークユーザーの認証情報が IAB 経由で Lapsus$ に販売されたことが攻撃の発端だと主張しています。その後、攻撃者が何度も認証情報の使用を試みたため、契約者のスマートフォンに Duo Security から多要素認証プッシュ通知が何度も送られました。契約者が大量の通知にうんざりし、そのうちの 1 つを受け入れたことが、侵入の足がかりとなりました。

Uber 側は、侵入者による権限昇格インシデントだと述べていますが、Telegram 上の会話では、侵入者は Uber の特権アクセス管理 (PAM) ツールの管理パスワードを含む PowerShell スクリプトを発見したと主張しています。このパスワードのおかげで、侵入者は、Uber の社内ネットワークに自由にアクセスできるようになったのです。

入手したアクセス権により、侵入者はネットワークを徘徊し、社内ツール、クラウドサービスのダッシュボード、セキュリティダッシュボードなどのスクリーンショット、さらにはセキュリティバグ報奨金プログラム管理システムへのアクセスを強引に取得しました。

自社のシステムに対する同様の攻撃から身を守るには、どうすればよいのでしょうか。本記事では、今回の攻撃が成功した具体的な理由をいくつか紹介し、自社のセキュリティ体制を強化するための教訓としてどのようなことが得られるかを考えます。

多要素認証だけでは不十分？

多要素認証の導入が進むにつれて、攻撃者はあの手この手で多要素認証を迂回するようになっています。Uber は、VPN リモートアクセスサービスを保護するために、Cisco のプッシュ通知サービスである Duo を導入していましたが、これは素晴らしいことです。問題は、標的にしつこくアラートを送信すると、しばしば標的がうんざりして [承諾] を押すことを攻撃者が学んでしまったことです。

では、どのような対策があるのでしょうか。何も制約が無いのであれば、FIDO2 認証の使用が推奨されます。しかし、FIDO2 認証では、認証するデバイスに物理的に近接したハードウェアトークンまたはスマートフォンが必要です。

しかし、誰しもにこの技術を採用する用意があるわけではないので、Duo のような多要素認証サービスでは、本人に直接 6 桁のコードを送信し、デバイス上で [承諾] をタップする代わりに、そのコードを入力させるという、プッシュ通知と複合させた認証方法も提供されています。この場合、攻撃者は被害者を唆し、自分の代わりにコードを入力するように誘導する必要があります。全く不可能なことではありませんが、単に [承諾] と書かれた緑色の大きなボタンを押させるよりははるかに大変です。

権限昇格: (ネットワークを通じた) 時間稼ぎ

攻撃者は大抵、十分な時間さえあれば、正規ユーザーが本来アクセスできないはずのアカウントにアクセスできるように権限を昇格させてしまいます。この種の攻撃に対する防御では、攻撃者のフットプリントを検知し、権限昇格が成功する前に攻撃者を撃退できるよう、時間稼ぎを行うことが重要です。

攻撃者は、Uber の特権アクセス管理ツールの管理者パスワードを、ユーザーがアクセス可能なファイル共有内の PowerShell ファイルから発見したと主張しています。管理者パスワードを誰でも閲覧可能な場所に置いておくのは明らかに良いことではありませんが、それでも 1 つの疑問が生じます。たったそれだけのことで、なぜここまで大騒ぎしているのでしょうか。

攻撃を受けた Uber のシステムがどのようなものであったかはまだわかりませんが、多くの人は、なぜ多要素認証が導入されていなかったのかと疑問に思われるでしょう。しかし逆に、自社の社内システムへのログオンには多要素認証が導入されているでしょうか。権限管理、ソースコード、人事、財務などの重要な機能については、ネットワークにアクセスするユーザーを認証するときと同様の注意を払う必要があります。また、ネットワーク全体に対して認証されているからと言って、機密システムへのアクセスが許可されているとは限らないことに注意しましょう。

半年に一度、外部の侵入テストを実施するのと同じように、このような事態を想定して内部環境の監査を行うのも良い方法です。一時的な回避策であったり、忘れ去られた慣習と化してしまっているかもしれませんが、このような事態は、ある程度複雑なネットワークであれば、いつでも発生するものです。

複数回の認証とゼロトラストネットワークアクセス

ゼロトラストネットワークアクセス (ZTNA) の主な考え方は、必要なときに必要なものにだけアクセスを認めるべきであり、ユーザーの自己申告を決して信用しないということです。ZTNA を用いると、外部向けのアプリケーションと同様に、アクセス時に各ユーザーの権限を認証し、すべてが申告通りであることを確認します。

この手法の利点の 1 つとして、境界が完全に消失することが挙げられます。少なくとも、VPN タイプのツールへの依存が解消され、ファイアウォールと WAF の背後にある、資産保護のための大規模なレイヤーを縮小できます。しかし、すべてのアクセス要求が認証/許可されていることをしっかりと、慎重に確認することは、実際、より優れた資産管理だと言えます。また、問題が発生した際の発見も容易になります。

ネットワークは、チョコレートバーのように、外殻が硬く中心部が柔らかいものであってはいけません。Uber のニュースが最初に報道された際に Paul Ducklin とポッドキャスト (リンク先: 英語) で話したように、最も適切に管理されたネットワークは、ある程度の侵害を前提としています。悪意のある人の手に渡ると危害を加えられる危険があるものを、その辺に転がしておいてはいけません。

結論

セキュリティに関するニュースが報道されるたびに、教訓を得て、同じような攻撃者に直面した時に自社のチームがどう対処するかを想像するのもベストプラクティスの 1 つです。ネットワーク防御を成功させるのは容易ではありませんが、教訓を活かして洗練させていくことで、少しずつ改善できます。

多層防御は、いずれかのレイヤーが魔法のように攻撃を抑止することに期待するのではなく、各層が時間を稼ぐものだと捉えるべきでしょう。

その間に、システムを監視しているチームが異常に気付き、調査を開始できます。多層防御の目標は、多数のレイヤーで十分な時間を稼ぎ、侵入口を見つけて閉鎖し、攻撃者が目的を果たす前に撃退することです。

攻撃者の目的がマルウェアの仕込み、特定の知的財産の窃取、あるいはランサムウェア/恐喝攻撃の実行である場合、通常は数日必要であり、その間足止めができれば対処も可能なはずです。

残念ながら、Uber や Rockstar、その他の Lapsus$ の被害者の場合と同様に、攻撃者は、騒動を引き起こし、被害者に恥をかかせるためだけに、あらゆることを狙っています。この種の侵入は、ほとんど時間を要しません。一方で、ネットワークとその監視は最高の状態に保っておく必要があります。

これらのインシデントによる被害は一時的なものです。最終的には自社の防御プロセスやアークテクチャの改善に活かすことができれば、良い結果を得られるでしょう。セキュリティは進化し続ける分野です。お互いに協力し、失敗から学び、攻撃のハードルを上げ続ける必要があります。