Bay Area Tech Blog #52
Uberハッキングに関するまとめ
Uberがハッキング被害に合いました。ニュースで知ってから実際の攻撃手法や被害状況を調べてみると、とても興味深く感じたのでまとめてみました。今回の事件はケーススタディとして学べるところも多いはずです。
Uberがハッキングされた
2022年9月15日にUberがハッキングを受けました。発覚したのは、バグバウンティ(バグ発見者に懸賞金を授与する)プラットフォームであるHackerOneに投稿されたメッセージでした。
なお、この投稿によるとドメイン管理者、AWS管理者、VMware vSphere管理者、Google GSuite (Google Workspace)、HackerOneのアカウントがハッキングされているとあります。ただ、後述しますが実際どこまでのアカウント情報を取られたかについては、Uberの発表と攻撃者の主張が異なっています。
犯人はLAPSUS$
Uberの発表によれば犯行はLAPSUS$ハッキンググループによって行われたようです。LAPSUS$は有名な犯行グループでして、2022年だけでもマイクロソフト、シスコシステムズ、サムスン、NVIDIA、Oktaが被害に合っています。
さらに、報道によれば不正アクセスに関与した攻撃者は、Tea Potというニックネームを持つ18歳の若者ということです。
侵入方法は多要素認証の回避
さまざまな情報をまとめてみると大きく分けて3つの攻撃があったように思えます。
アンダーグラウンドサイトから認証情報を購入
多要素認証を回避
HackerOneから脆弱性レポートをダウンロード
1. アンダーグラウンドサイトから認証情報を購入
Uber社員がマルウェアに感染 → マルウェアが認証情報を収集 → 収集された情報がアンダーグラウンドで販売 → 今回Uberをハッキングした攻撃者(Tee Pot)が購入、といった流れのようです。
(Tee Potはマルウェア感染には関わっていない)
Group-IBがLinkedInに投稿した内容をみると、攻撃者が購入したのは、UberのOneLogin(ID管理のSaaS)、Slack、Facebook、Google、Instagramなどの認証情報です。また、アンダーグラウンドで販売されていたUber社員(判明しているところではインドネシアとブラジル)のアカウントは、パスワード、Webブラウザのクッキーやオートフィル、さらにシステムのIPアドレスや位置情報などを収集するRacoonおよびVidarに感染していました。
なお、攻撃者は9月12日と14日に売りに出された情報を購入し、15日に攻撃をしかけていることから、ものすごく短い時間で攻撃に成功したことが分かります。
2.多要素認証を回避
攻撃者は盗み出した認証情報(アンダーグラウンドで購入したもの)を使って不正アクセスを成功させました。その際、興味深いのは多要素認証のプッシュ通知を1時間以上何度も送りつけて、ユーザーにMFA疲労を起こさせてYESボタンを押させたことです。さらに、ターゲットになっていたユーザーにチャットアプリWhatsAppでUberのITチームからと偽って連絡をし、「MFAの通知を止めるには認証を受け入れてください」と伝えました。WhatsAppは一般的に個人で利用されていることから、おそらく犯人は上述したアンダーグラウンドで購入したFacebookやInstagramの情報をもとにターゲットのWhatsAppアカウントを特定したのだと筆者は予測しています。
3. HackerOneから脆弱性レポートをダウンロード
攻撃者は前述したバグバウンティプラットフォームHackerOneにある脆弱性レポートをダウンロードして情報を集めていたようです。これに対し、HackerOneのCEOであるMarten Mickos氏は、Uberのアカウントをロックし、同社はUberと協力して調査に協力していると述べています。
VPNを通じて社内イントラに侵入したと攻撃者が主張していることから、侵入後にダウンロードした脆弱性情報を持ちいて、ラテラルムーブメントなどを仕掛けた可能性もあります。
被害はどこまで広がったのか？
Uberの発表している情報とセキュリティ調査団体が発表している内容が異なっているため、実際の被害状況を正確に把握するのは現時点では難しいと思っています。争点は社内システムにどこまでアクセスされて、どのような情報が盗み出されたのかというところです。
Uberが発表している内容
個人情報や財務情報（クレジットカード番号、ユーザーの銀行口座情報、個人の健康データ、旅行履歴など）を含む機密性の高いユーザー情報を保管する本番システムにアクセスできたという証拠は見つからなかった
コードベースにアクセスされ悪意のあるコードを注入されたという証拠は見つかっていない
従業員が社内ツールにアクセスできなくなった
Uberの財務チームが使用している社内ツールの請求書の一部や、HackerOneの脆弱性レポートなど、機密情報にアクセスされた
攻撃者が主張している内容
Uber社内のSlackに侵入、“I am a hacker and uber has suffered a data breach,”と書き込んだ (こちらはWall Street Journalでも報道されている)
イントラネットにログインし、さまざまな管理者アカウントを入手
攻撃者(Tea Pot)とチャットアプリで連絡を取ったところ、Tea PotはUberのネットワーク共有フォルダからPowerShellスクリプトにアクセスした
PowerShell内にThycoticの管理者アカウントとパスワードがハードコーディングされていたのでAWS、Cisco DUO、Google GSuite, Oneloginなどへアクセスキーを手に入れることに成功できた
(ただ、通常スクリプトなどのコードの中にアカウント情報をそのまま入れるのはご法度となっているため、この攻撃者の主張が本当かどうかは怪しいと感じました)一方でUberの社内ITシステムのスクリーンショットだと主張する画像もTwitterでは公開されています (本物かどうかは検証できていません)
Uberが取った対策
この攻撃に対してUberはどのような対策を行ったのでしょうか？Uberの発表によると取られた対策は以下のとおりです。
漏洩もしくは漏洩の可能性がある従業員のアカウントを特定し、Uberのシステムへのアクセスをブロックするか、パスワードをリセットした
影響を受けた、または受ける可能性のある社内ツールを無効化した
多くの社内サービスのキーをローテーションした
(事実上のアクセス権リセット)コードベースをロックダウンし、新たなコード変更を防止した
社内ツールへのアクセスを回復する際には、従業員に再認証を求めた
内部環境の監視を追加し、不審な動きをより注意深く可視化できるようにした
Uberハッキングから学べること
今回のハッキング事件をケーススタディとして、以下のような防衛をしてみてはいかがでしょうか。もちろん、これですべてが防げるわけではないかと思いますが、同様の手口を防ぐのに有効かと思います。
1. 社員への教育
今回MFA (多要素認証)を回避できたのは、Uber社員がWhatAppで連絡されたことで、攻撃者から騙されていることに気がつけなかったからだと思います。そこで、例えば以下のようなポリシーを決めて周知しておくといいでしょう。
社内ITから個人の端末に直接チャットを送ることがないということを普段から繰り返し伝えておく
インシデントが発生した場合の連絡方法を決めて継続してアナウンスする(例えば社内ポータル、特定のメールアドレスからのメール連絡など)
2. MFA(多要素認証)の強化
今回のハッキング事件でMFAは設定されていたものの (攻撃者側の発表では) プッシュ通知だけだったそうです。最近のMFAは位置情報を追加したり、番号照合を追加したりすることが可能です。このような情報を追加することで、本当に自分がログインした時に送信された通知なのかどうかユーザーが判断しやすくなります。Azure ADでの設定方法はこちらのブログで紹介されていますし、他にも調べれば出てくると思いますので、ぜひ参考にしてみてください。
さらにMFAのセキュリティを高めたい場合は、1Kosmosのソリューションもおすすめです。1Kosmosではブロックチェーンネットワーク内に保存した個人情報(生体認証、運転免許証など)を用いてパスワードレス認証を利用することが可能になります。JefferiesやBlackRockといった米国の大手投資銀行、また、Netsmart TechnologiesやDrFirstなどの医療サービスが1Kosmosを導入しています。
3. 認証情報をハードコーディングしない
今回の攻撃者(Tee Pot)によれば、Uberの社内共有フォルダに置いてあったPowerShellの中に認証情報がそのまま入っていました。一般的にはコードの中に認証情報を埋め込むことがご法度であることはよく知られていると思いますが、開発環境が大きくなるにつれて見逃してしまったり、自動化ツールが勝手に埋め込んでしまったりというケースも否めません。たとえばConcourse LabsのようなSecurity-as-Codeのソリューションを使うことでこのようなミスを発見することも可能です。環境が大きくなるに伴って人手で発見することが難しくなると思うので、この手のツールを積極的に利用されてはいかがでしょうか。
4. AWSの鍵を使わないようにする
AWS IAM Instance Profile や GCP Application Default Credentials などのようにアクセス権を付与するアプローチを検討しましょう。今回の事件のように攻撃者がAWSやGoogleの認証情報を盗み出したとしても、アクセスできる範囲を狭めることができます。
5. APIセキュリティを導入する
今回Slackにログインされ不正な書き込みも行われていますし、ひょっとするとAPIトークンも流出してしまっている可能性があります。このような場合に、企業ポータル、社内管理システム、特権アクセス管理(Privileged Access Management: PAM) などを保護するために、APIセキュリティが役に立つと思います。流出したAPIトークンのブロックや調査を効率化できます。
おまけ
今回のハッキング事件を受けて、LinkedInにはUberのセキュリティエンジニアの募集が大量に追加されたそうです。とはいえ、これはLinkedInのとあるユーザーが飛ばしたジョークの可能性もあります。ただ、サイバーセキュリティの予算が増えるのは事件が起きてからなどとよく言われますので、あながちただのジョークではないかもしれませんね。
