Uber 2022年 委託先のパスワードと多要素認証の通知の承認

外部の契約者の会社のパスワードで繰り返しログインを試み、届き続けた承認の通知の1回が許された。多要素認証は入っていたが、押すだけで通る形は、人が根負けした所で破れる。入ったあとは他の社員のアカウントを経て、社内の道具の上の権限まで届いた。

発覚と対応の始まりは2022年9月15日[1]。Uber が2022年9月15日、16日、19日に出した発表に沿って書く[1]。Uber は9月19日の時点で、影響を受けた社員のアカウントを止め、社内の多くの仕組みの鍵を回し、コードの変更を止め、利用者の機微な情報への侵入の証拠は無いとした[1]。対策の型は、米国の Cyber Safety Review Board が2023年7月24日付で出した Lapsus$ の件の報告に拠る[2]。2026年11月時点の公開資料で書いています。

要点

  • 入口は外部の契約者のアカウント。個人の端末がマルウェアに感染したあと、会社のパスワードを闇のサイトで買われた可能性が高い、と Uber は書く[1]。
  • 多要素認証は、はじめは侵入を止めていた。繰り返しのログインのたびに承認の要求が届き、契約者が最後に1つを許した[1]。
  • 入ったあと、他の社員のアカウントを使い、G-Suite と Slack を含む複数の道具の上の権限を得た[1]。1人の委託先の侵入が、社内の広い範囲へ届いた。
  • Uber は、本番の仕組みと利用者の機微な情報への侵入は見ていないとし、Slack のメッセージの一部と、経理の請求書の道具の情報が取られたと書く[1]。
  • 根本の守りは、通知を押すだけの多要素認証をやめ、フィッシングに強い方式へ移すこと。CSRB は、FIDO2 の物理の鍵が最も強かったと書く[2]。

何が起きたか

日付の知られていないパスワードの流出、9月15日の発覚、16日の続報、19日の詳しい説明の4つの段 1 流出 日付は公表されず 個人の端末に感染 パスワードが売られる 2 発覚 2022年9月15日 対応中と発表 法執行機関と連絡 3 続報 9月16日 止めた道具を戻す サービスは平常 4 説明 9月19日 道筋、影響、対応 Lapsus$ と関連づけ 2から4は4日。侵入の始まりの日時は発表に無い 時刻はいずれも米国の太平洋時間
図1 発覚から説明までの段
日付出来事
日付の公表なし外部の契約者の個人の端末がマルウェアに感染し、その後、契約者の Uber の会社のパスワードが闇のサイトで買われた可能性が高い[1]
2022年9月15日 午後6時25分Uber が、サイバーセキュリティの事案に対応中で、法執行機関と連絡を取っていると発表する[1]
2022年9月16日 午前10時30分利用者の機微な情報、たとえば乗車の履歴への侵入の証拠は無いと発表する。Uber、Uber Eats、Uber Freight、運転手のアプリは動いており、前日に念のため止めた社内の道具を戻しつつあるとする[1]
2022年9月19日 午前10時45分何が起きたか、影響、対応、誰によるかを発表する。Lapsus$ と呼ばれる集団に関わる者と考えている、FBI と司法省と緊密に連携していると書く[1]
2023年7月24日CSRB が Lapsus$ と関連の集団の攻撃についての報告をまとめる。ある組織の対応として、Uber の9月19日の発表を引く[2]

通った道筋

個人の端末の感染からパスワードが買われ、繰り返しのログインと承認の通知の1回の許可で契約者のアカウントに入り、他の社員のアカウントから社内の道具の上の権限へ広がる 契約者の個人の端末 マルウェアに感染 会社の管理の外 会社のパスワード 闇のサイトで 買われた可能性が高い 繰り返しのログイン 毎回、承認の要求が届く はじめは止めていた 1つを許す ログインに成功 他の社員のアカウント 複数に入る 上の権限 G-Suite と Slack ほか Uber が発表した、入ったあとにしたこと 全社の Slack に投稿 OpenDNS の設定を変える Slack のメッセージを取る 経理の請求書の道具 HackerOne の管理画面 本番とコードに跡なし
図2 委託先のパスワードから社内の道具の権限まで
段Uber の発表
パスワード外部の契約者のアカウントが侵害された。契約者の個人の端末がマルウェアに感染したあと、会社のパスワードを闇のサイトで買った可能性が高い[1]
多要素認証攻撃者は繰り返しログインを試み、そのたびに契約者に2段目のログインの承認の要求が届き、はじめは侵入を止めていた。最後に契約者が1つを受け入れ、ログインに成功した[1]
広がりそこから他の複数の社員のアカウントに入り、G-Suite と Slack を含む多くの道具の上の権限を得た[1]
したこと全社の Slack のチャンネルに投稿し、Uber の OpenDNS の設定を変えて一部の社内のサイトで画像を出した。経理の請求書の道具の情報に触れるか取り、社内の Slack のメッセージの一部を取った[1]
HackerOne研究者が弱点を届ける HackerOne の管理画面に入った。触れられた届け出はすべて直してある、と Uber は書く[1]
無事だった所アプリを動かす公開の本番の仕組み、利用者のアカウント、カード番号や口座や乗車の履歴を置くデータベースへの侵入は見ていない。コードを調べ、変更は見つかっていない[1]
広く伝わる話のうち、Uber の発表に無いもの

報道や各社の解説には、攻撃者が社内の支援の係を装ってメッセージで承認を促した、社内のネットワークの共有の場所にあった PowerShell のスクリプトに管理者の資格情報が書かれていた、という話がある。Uber の3回の発表は、どちらも書いていない[1]。CSRB の報告は、Lapsus$ 系の手口の例として、支援の係を装う連絡と、誤って共有されたネットワークの場所の PowerShell のスクリプトに埋め込まれた特権の資格情報を挙げるが、組織の名前を書かず、後者の出典は警備の会社のブログである[2]。

多要素認証のどこが破れたか

押すだけで許す通知の方式は、許すかどうかを人の判断に預ける。届いた要求が自分のログインかどうかを、人は画面から確かめられない。CSRB は、Lapsus$ 系の攻撃者が承認の通知を浴びせ、ときに夜中や都合の悪い時間に送って、従業員が許すまで続けたと書く[2]。

押すだけの通知、番号の照合、FIDO2 の3つで、承認の連打とフィッシングに耐えるかを比べる 押すだけの通知 届いた要求を許すか拒む どのログインかを確かめない 連打に弱い フィッシングに弱い この件の形 番号の照合 ログインの画面の番号を アプリに打つ 連打に強い フィッシングに弱い すぐ移れない時の次善 FIDO2 鍵がサイトの宛先に 結びついて署名する 連打に強い フィッシングに強い 物理の鍵が最も強かった
図3 多要素認証の方式と、耐える攻撃
  • CSRB は、番号の照合の無い押すだけの通知は連打と人の誤りに弱く、番号の照合や使い捨ての番号はフィッシングには弱いままだと書く。CISA は、フィッシングに強い方式へすぐ移れない組織に、通知より番号の照合か使い捨ての番号を勧める[2]。
  • 番号の照合で改善した組織があり、物理の鍵による FIDO2 が最も強かった、と CSRB は書く[2]。
  • Uber は9月19日に、多要素認証の方針をさらに強めているとだけ書き、何に変えたかは書いていない[1]。

どこで止められたか

端末、パスワード、多要素認証、委託先の権限、検知と対応の5つの段に、それぞれ止める所を置く 個人の端末 パスワード 多要素認証 委託先の権限 検知と対応 1 会社の資格情報を個人の端末に置かない 管理の外の端末は、感染しても会社に見えない 2 流出したパスワードを見張る 売られた組を見つけたら、すぐ変えて止める 3 押すだけの方式をやめる この件で破れた所。FIDO2 か番号の照合へ 4 1つのアカウントから広げない 他の社員の資格情報と上の権限に届かない作り 5 拒まれた要求の連続で警告する 止める、回す、戻す前に認証し直す
図4 段ごとの止める所
止める所この件で限り
会社の資格情報を個人の端末に置かない感染したのは契約者の個人の端末だった[1]委託先の端末を会社が管理できない契約は多い。端末で守れない分を、次の段で受ける
流出したパスワードを見張るパスワードは闇のサイトで買われた可能性が高い[1]売られた事実に先に気付けるとは限らない
押すだけの方式をやめる多要素認証は、はじめは止めていた。破れたのは、許すかどうかを人が決める所だった[1]番号の照合はフィッシングの画面には弱いまま[2]
1つのアカウントから広げない契約者のアカウントから、他の社員のアカウントと、G-Suite と Slack ほかの上の権限に届いた[1]。どう届いたかは発表に無い道筋が公表されていないので、どの守りが効いたかは言えない
拒まれた要求の連続で警告する既存の監視で早く気付き、対応に移れた、と Uber は書く[1]侵入から気付くまでの時間は発表に無い

Uber がした対応

対応発表の中身
アカウント侵害されたか、その恐れのある社員のアカウントを洗い出し、止めるかパスワードを変えさせた[1]
社内の道具影響を受けたか、その恐れのある多くの社内の道具を止めた。戻す時は、社員に認証をし直させた[1]
鍵社内の多くの仕組みの鍵を回し、実質的に入る権限をやり直した[1]
コードコードの置き場を締め、新しい変更を止めた[1]
監視社内の環境の監視を足した[1]

CSRB は、ある組織が既存の監視で気付き、影響のある道具を止め、コードの変更を止めた例と、道具を戻した後に全社員に認証をし直させた例として、Uber の9月19日の発表を引く[2]。入られた後の手順は、事前に決めておけば、発覚の日に迷わず回せる。

守り方

根本の直し方
  • 社員と委託先のすべての入口で、フィッシングに強い多要素認証を求める。CSRB は、FIDO2 に沿った、パスワードの要らない方式を勧める[2]。
  • すぐ移れない間は、押すだけの通知をやめ、番号の照合か使い捨ての番号にする[2]。
  • 委託先のアカウントは、仕事に要る道具だけに絞り、期間を区切る。1つのアカウントから他の社員の資格情報と管理の権限に届かないよう、資格情報を共有の場所やスクリプトに書かない。
  • 重要な操作の前に、改めてフィッシングに強い方式で認証させる。CSRB は、機微な取引ごとに明示の認証を求めるよう勧めた[2]。

架空の会社の認証の記録。拒まれた承認の要求が続いたあとの許可

2026-03-02T01:12:04Z push_sent    user=ext-dev07  src=198.51.100.23  result=denied
2026-03-02T01:13:40Z push_sent    user=ext-dev07  src=198.51.100.23  result=denied
2026-03-02T01:15:02Z push_sent    user=ext-dev07  src=198.51.100.23  result=timeout
# ... 同じ形が続く
2026-03-02T01:41:57Z push_sent    user=ext-dev07  src=198.51.100.23  result=approved
2026-03-02T01:42:10Z login        user=ext-dev07  src=198.51.100.23  device=new

架空の検知の規則。拒否の連続のあとの許可を、許す前と後で止める

rule: mfa_push_burst
  when: count(push_sent where result in [denied, timeout]) by user within 30m >= 3
  then:
    - block_push user           # その利用者には通知を送らず、物理の鍵だけを受ける
    - alert soc                 # 夜間でも当番に届ける
    - require_reauth user       # 次の許可のあとのセッションは開かない
  • 許したあとに気付く規則では遅い。拒否の連続を見た時点で、その利用者への通知を止める。
  • 利用者には、身に覚えの無い要求を拒むだけでなく、届け出る窓口を用意する。CSRB は、偽の認証の要求を従業員が知らせられるようにした組織の例を挙げる[2]。
緩和の策
  • 新しい端末と、いつもと違う場所からのログインに、別の確かめを足す。
  • セッションの長さを短くし、重要な道具は再認証を求める。CSRB は、事後にセッションを短くした組織があったと書く[2]。
  • 入られた時に、攻撃者に見られない連絡の手段を先に決めておく。CSRB は、対応のやり取りを攻撃者から隔てた組織の例を挙げる[2]。
  • 弱点の届け出の管理画面のように、まだ直していない弱点が集まる所は、上の権限のアカウントからも分けて守る。

パスワードと多要素認証の規則は A07 認証の不備 に、記録から警告と対応までが途切れる所は A09 セキュリティログとアラートの不備 に、資格情報を共有の場所やスクリプトに置かない考え方は 秘密の鍵の扱い にある。

参照

  1. Security update Uber、2022年9月15日、16日、19日
  2. Review of the Attacks Associated with Lapsus$ and Related Threat Groups Cyber Safety Review Board、2023年7月24日