LastPass、別のデータ漏えいをユーザーに通知

 (9to5mac.com)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • LastPassユーザーは、外部パートナーであるKlueの侵害事故により個人データとサポートケースデータが露出したとの通知を受けた
  • 今回の事故でのアクセス範囲は、標準的な業務連絡先情報、CRMデータ、サポートケースデータ、営業関連データに限定されており、パスワード保管庫は影響を受けていない
  • 露出した項目には顧客名、電話番号、メールアドレス、実住所が含まれ、KlueプラットフォームはSalesforceとGongのシステムに統合されている
  • 事故を把握した後、LastPassは従業員のKlueへのアクセスを取り消し、露出したAPIトークンを交換するとともに、法執行機関への通知とKlue・Salesforceを通じた調査を進めている
  • 漏えいした連絡先情報はフィッシングやソーシャルエンジニアリング攻撃に悪用される可能性があるため、顧客と企業は共有された攻撃指標を確認する必要がある

Klue侵害事故とLastPassの対応

  • 市場調査企業Klueで発生した侵害事故の影響で、LastPassが該当ユーザーにメールを送信した
  • ハッカーは侵害を通じて顧客情報とサポートケースデータにアクセスできた
  • アクセスされた情報は次の範囲に限定される
    • 顧客名、電話番号、メールアドレス、実住所
    • 顧客関係管理（CRM）データ
    • サポートケースデータ
    • 営業関連データ
  • 今回の事故でLastPassのパスワード保管庫は影響を受けていない
  • KlueプラットフォームはSalesforceおよびGongシステムと統合されている
  • LastPassは事故対応としてアクセス遮断と調査手続きを進めている
    • 従業員のKlueへのアクセス権を取り消し
    • 露出したAPIトークンを交換
    • 法執行機関へ通知
    • KlueおよびSalesforceとの連携を通じて事故範囲を調査

攻撃指標と過去のセキュリティ事故

  • 顧客は、漏えい情報を利用したフィッシング攻撃やソーシャルエンジニアリングの試みに注意する必要がある
  • 企業が関連活動をシステム内で検索できるよう、攻撃者に関する指標が共有されている
    • IPアドレス:
      • 138.226.246[.]94
      • 94.154.32[.]160
      • 159.183.215[.]61
      • 159.183.181[.]239
    • メール送信ドメイン:
      • baccarat.com[.]au
      • robinskitchen.com[.]au
      • house.com[.]au
  • LastPassは過去にも複数回セキュリティ事故を経験している
    • 2015年にはアカウントのメールアドレス、パスワードヒント、認証ハッシュ、暗号化ソルトが窃取されたが、暗号化された保管庫データへのアクセスはなかった
    • 2022年には攻撃者が開発者アカウントを侵害してソースコードと技術情報を盗み、その後これを利用して顧客記録と暗号化されたパスワード保管庫を含むクラウドバックアップにアクセスした
    • 同じ2022年の事故には、氏名、請求先住所、メールアドレス、電話番号といった非暗号化情報も含まれていた

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • もう誰が LastPass を本気で信頼できるのか分からない
    数年前に銀行データを扱う会社で働いていたが、以前のLastPassのセキュリティ事故の直後でも使い続けていて、移行する計画もなかった

    • 多くの人や組織は、セキュリティ製品を セキュリティ のためではなく セキュリティ劇場 のために使っている
      大半の人、セキュリティ担当者でさえ今回の侵害を聞いていない人が多いだろうから、LastPassは彼らにとってはまだ十分機能しているということになる
    • パスワードがまだ知られていないなら、その「侵害」はエンドユーザーの観点では失敗ではない
      保管庫の マスターパスワード が安全で、保管庫にアクセスする唯一の方法が依然としてマスターパスワードだけなら、エンドユーザーが求める機能は果たしている
      「侵害」という言葉は条件を付けなければ意味がない
    • 何百社ものセキュリティコンサルをしてきたが、実際にセキュリティを真剣に受け止める会社は過去に 侵害を受けた会社 だった
      経営陣や取締役会がコスト影響を直接見るまでは、ただ記事を読むだけではセキュリティプログラムに必要な予算は決して付かない
      だからといってその理由でLastPassを勧めるわけではないが、その理由だけで完全に除外はしない
    • すべてのパスワードと暗号鍵を 第三者 に預けることをどう信頼できるのか理解できない
      KeePassXC のセットアップはとても簡単だ

  • 影響を受けた会社ははるかに多い。下にも一部が挙がっている

    "Klue has not said how many of its hundreds of customers are affected. Several companies have come forward to confirm they had data stolen during the attack, including Gong, Jamf, HackerOne, Insurity, OneTrust, Recorded Future, Snyk, Sprout Social, and Tanium."
    Cybercrime group Icarus took credit for the breach, saying on its leak site that it will publish the stolen data on Monday if the company does not pay the hackers’ ransom."
    https://techcrunch.com/2026/06/22/klue-hack-results-in-data-...

  • LastPassがいったいなぜ顧客の詳細情報を 市場調査会社 に渡しているのか分からない
    そういうデータは、名前や具体的な住所などを除いて完全に匿名化されるべきだった
    おすすめを探している人には KeepassXC と Keepass2Android を使っている。オープンソースで、ローカルデータベースを使い、同期するかどうかも自分で選べる。私は Own cloud で同期している

    • 私は何年も pwsafe を使っている
      これも無料のオープンソースで、ローカル専用の保管庫だ。無能なせいでデータを失うクラウドサービスに依存する必要がない
      必要なら保管庫をDropboxやiCloud Driveに保存することもできるが、なぜわざわざそうするのか分からない

    • Any such data should have been fully anonymized: no names, no specific addresses, etc..
      そもそもなぜそんなデータを渡す必要があるのか？

  • https://blog.lastpass.com/posts/klue-supply-chain-incident-a...

    The information accessed was limited to standard business contact information and related customer relationship management (CRM) data, including customer names, phone numbers, email addresses, and physical addresses, as well as support case data and sales-related data.

  • このやり方もある意味ではLastPassを使うより悪いかもしれないが、この数年、パスワードの90%はただ生成して忘れている
    残りの10%だけ パスワードマネージャー に保管している。あまり重要でないサービスなら、ログインするたびに「パスワードを忘れた」で新しいパスワードを作って変えている

    • アカウントに 二要素認証 がなければこのやり方は通用する
      最後のサイドプロジェクトのアプリでは、ユーザーはメールのワンタイムパスワードでしかログインできなかった
      偽サイトにワンタイムパスワードを入力させるフィッシングのようなセキュリティ上の欠点はあるが、機密情報を保存しないアプリだったので、大きなセキュリティリスクではないと思う
    • 以前の電話番号にもうアクセスできず、その番号に 二要素認証SMS が送られる設定になっていて困ったことがある
    • だから多くのサービスがログイン方法としてメールの マジックリンク を使う方向に移っている
      結局、多くのサービスではメールを乗っ取ることが実質的にログインを乗っ取ることになる

  • 私は生涯ライセンスを安く買えたので、何年も Enpass を使っている
    Enpassはパスワード同期のためのクラウドサービスを自前でホストせず、ユーザーがクラウドストレージに認証すると、そこへ同期する。私はGoogle Driveを使っている
    このアプローチのほうが良いと思う。悪意ある誰かが私のGoogleアカウントに入れたなら、どうせ終わりだし、おそらくパスワードマネージャーに入られるよりひどい
    しかも、中央の一か所が侵害されたら大当たりになるようなデータの山を作らない。Enpassの全パスワードを盗むには、Google Drive、Dropbox、iCloudなどを全部ハックしたうえで、ファイルを手動で探さないといけない

    • それは例えば KeePass とどう違うのか？

  • また別の侵害を理由にLastPassをみんなで叩き、顧客データを第三者に渡すなんて完全に無責任だと言うのは面白いが、実際に何が起きたのか少し見るだけで、頭の中の物語と現実がかなり違うと分かる
    Klue は多くの営業チームが使っている顧客関係管理サービスの一つだ。顧客の連絡先メールや財務部門のような顧客記録を渡すことで、Klueはその顧客について「市場情報」のようなものを提供できる
    営業チームに行って、システムに接続している雑多なものを見れば、似たようなものが見つかる可能性が高い
    これが良い考えかどうかは別として、私は強く嫌っているが、今どき営業チームはこうやって仕事をしている。取り上げようとすれば営業組織全体と戦うことになる
    むしろ、こういう侵害がもっと頻繁に起きないことのほうが驚きだ
    LastPassの実際の パスワードデータベース には影響がない
    関係するどの組織とも私は無関係だ

    • I am more surprised that these breaches don't happen more often.
      実際にはよく起きている

  • LastPassはそろそろ First0wned にリブランドすべきだと思う

  • 保管庫が流出した後でもLastPassを使い続けたり新規導入した会社なら、今回の件はただの CRMデータ なのでまったく気にしないだろう
    LastPassを使い続ける会社にはある程度共感する。組織をLastPassから1Passwordに移行しなければならなかった時は、とてつもない作業で本当に面倒だった
    でも2022年以降にLastPassを選んだ人には共感しにくい

    • ここで大したことがない部分は、データの重要度が低いことだ
      本当の核心は、どれだけ些細でもLastPassならもっと上手くやるべきだったという点にある
      パスワード保管会社なら、信頼されるためにこの程度では駄目だ

  • かなり前にLastPassを捨てて BitWarden に移ったが、今はだいたいAppleのPasswordsアプリを使っている