#1641: LastPass 漏洩、Live Text でレシピ入力、MobileDeviceUpdater のインストール不具合を修正

macOS の内部で Apple が管理するあらゆるプロセスの中で、MobileDeviceUpdater ほど謎めいたものはあまりない。macOS が USB 接続された iPhone または iPad に接続しようとしてドライバのアップデートが必要となった場合にこのソフトウェア・エージェントがインストーラを起動するのだが、それは macOS の他のどんな活動とも違って見える。

MobileDeviceUpdater のアラートを見てこれはマルウェアかフィッシング攻撃ではないかと危惧する人たちはいるけれども、実はこれは本物かつ必要なアップデートであって、インストールしないとその Mac は iPhone や iPad とやり取りできない。デバイスごとに異なるスケジュールを使ってシステムをアップデートしているかもしれないので、macOS のバージョンが古くて新しいバージョンの iOS や iPadOS とやり取りできないという状況は大いにあり得る。

iPhone や iPad を Mac に繋いだらこのアラートが出たという場合には、Install ボタンをクリックする。すると、ダウンロード中およびインストール中という進行状況ウィンドウが開くはずだ。それが終了すれば、万事オーケーだ。少なくとも、オーケーなはずだ！

でも、インストールに失敗することがあり得る。そんな場合はどうすればよいのか？ インストールの終わりにそのダイアログが出ても、Apple は何の助言も提供してくれない。

私はそれまでこの問題を経験したことはなかったが、一月ほど前に iPad Pro を macOS 12 Monterey の走る 2020 年型 27 インチ iMac に接続しようとしてこれに遭遇した。私は同期しようとしていた訳でさえなくて、ただ単に充電したかっただけだ。iPad や iPhone を USB 経由で同期することはないので、インストールに同意しておけば同じアラートに悩まされることはなくなるだろうと気軽に考えた。なので、私が走らせたいとさえ考えていなかったそのインストーラがインストールに失敗したというダイアログを見た時の私の苛立ちを想像して頂けるだろうか？ まず iPad を、その次に Mac を再起動してみたが、状況は変わらなかった。

全くの偶然で、その数日後に TidBITS 読者の James Weil が問題の解決方法を TidBITS Talk に投稿してくれた。それは私にとって幸運の一日であり、もしかすると今日が皆さんにとっての幸運の一日かもしれない。次の手順を辿ればよい：

1. macOS 13 Ventura より前のバージョンの macOS では System Preferences > Sharing を開く。Ventura では System Settings > General > Sharing を開く。
2. 有効になっているすべてのサービスのチェックを外す。私の場合は Media Sharing と Content Caching と AirPlay Receiver にチェックが付いていた。
   

   

3. いったん iPhone や iPad へのケーブルを抜いてから、もう一度差し直す。
4. 再び MobileDeviceUpdater からそのプロンプトが出たら、Install をクリックする。今度はソフトウェアアップデートが正しくダウンロードされインストールされるはずだ。興味深いことに、失敗した時に比べてダウンロードにかなり長い時間がかかり、進行状況バーを数分間にわたって眺め続けることになった。つまりあれはダウンロードに関係する問題だったということだろう。
   
5. それから再び Sharing 画面を開いて、さきほどオフにしたサービスを有効に戻す。

こうして私は 12 月に問題に遭遇し、James の投稿を見て、この手順を辿ってアップデートに成功したのだったが、ついさっきまた同じエラーが出現したのを見てちょっとびっくりした。どうやらこのエラーは再現することがあるらしく、Mac と iPhone や iPad との間にずれが生じて新たなソフトウェアアップデートが必要となる度に同じ手順を繰り返さなければならないらしい。

ややこしいことに、どうやら問題はどのサービスが有効になっているかには無関係のようだ。有効になっていた３つのサービスのうちから１つずつオフにしたり、それを再有効化して次をオフにしてみたりいろいろ試した。当初、私は Media Sharing や AirPlay Receiver が原因になるとは思えず、きっとこれは MobileDeviceUpdater と Content Caching の間の問題だろうと想像していた。でも、そうではなかった。どのサービスでも走っていると MobileDeviceUpdater が止まってしまう。すべての共有サービスを無効化した場合にのみ、問題なくダウンロードとインストールが完了した。James が言った通りだ。

この解決法にはとてもとても不満足だ。まるで、その昔のデスクトップの再構築とか PRAM のザッピングとかいったものと同等の呪術的修正方法に思える。何がこの問題を起こしているかについてアイデアをお聞かせ願いたいと思っているところだが、何らかの説明を聞くまでの間は、上記の手順が本当に解決になると保証することはできない。でもまあ、少なくとも試してみるのは簡単だ。(もしもこの手順でうまくいかなかったならば、ぜひコメントでお知らせ願いたい。とりわけ、別の解決法があれば教えて頂きたい。)

Apple にはちゃんと時間をかけてこの問題をきっちりと修正してほしいものだ。

討論に参加

私は料理本が好きだ。ページをめくりながら、レシピはどれ程難しいだろうか、そしてどんな味がするのだろうかと想像してみるのが好きでたまらない。J. Kenji López-Alt や Deb Perelman の様な著者はとりわけ楽しいし、料理本には常に自分で盛ったよりもより美しい綺麗な写真が載っていることが多い。

しかし、私の最早秘密でも何でもない恥は、最初は夢中になった料理本でも、書棚に収まってしまうケースが多く、時折幾つかの限られたレシピのために引っ張り出されるだけとなってしまうことである。これ等の好みのレシピは付箋紙やしおりで目印とされることもある；もっと多くの場合、索引に頼ることとなる。Eat Your Books の検索可能なレシピ索引サイトの便利さは認めるが、それを習慣にまで持って行けたためしがなく ("料理用 Web サイト Eat Your Books" 17 March 2022 参照)、作るレシピを見付けるために、料理本をめくっていく作業を繰り返すこととなってしまう。

数年前、Tristan が大学で自炊を始め、自分が食べて育ったレシピを欲しがった時、我々は全面的に Paprika に頼った。それは素晴らしいレシピアプリで、iPhone, iPad, そして Mac のみならず Android や Windows でも使える (我々が最初に取り上げた記事 "FunBITS： iPhone、iPad、および Mac 用 Paprika Recipe Manager" 14 March 2014 を参照されたい)。当時、バンドルとしての提供があったかどうか覚えていないが - このアプリは個別に売られている - 我々にとっては Family Sharing はぴったりである。と言うのも Tonya, Tristan, そして私の全員が手近にあるどんな機器からも我々の家庭のレシピにアクセス出来るからである。

Paprika に関わる障害は - そしてアナログの料理本に代わるどんなデジタル選択肢でもそうだが - レシピをインポートすることである。システム全体の共有拡張を使ってウェブサイトから、或いは Paprika 内蔵の Web ブラウザの中でサイトを見ながらレシピをインポートするのは全く問題がない。しかし、多くの料理本は姉妹となるウェブサイトを持たないし、Cook's Illustrated の様な料理雑誌は紙の上で読めるレシピにデジタルでアクセスするのに対して腹立たしい余分な料金を課してくることすらある。

レシピを料理本や雑誌から Paprika へ転送するやり方を手早く行うのに使った私の最初のやり方は Voice Control の口述を使う事であった。それは今でも iOS/iPadOS 16 キーボードで提供されている改善された口述よりも能力で勝っている ("iOS と macOS の口述が Voice Control の口述から学べること" 31 August 2020 参照)。レシピをはっきり読めば転写はそう難しくはないが、句読点記号や改行を口に出す時には注意深くやる必要があることは言うまでもない。Web インポートと口述した Paprika 上のレシピの数は、今や 200 を超えるが、料理本からレシピを探す必要性は無くなっていない。

AI-駆動の画像スキャンの登場もあり、私は最近 Paprika が、私にレシピを写真撮らせてくれ、テキストを OCR し、そしてレイアウトを認識して、説明、材料、作り方、そしてメモと分けてくれはしないかと思ったりもした。悲しいことに、その答えはノーであったが、その様な機能は他のレシピアプリには存在しているものもある。例を挙げると、CookBook, 読者推薦の Mela,そして Recipe Keeper があるが、その機能のためだけで Paprika から離れたくはない。

しかしながら、スキャンする流れで考えてみた時、Apple が iOS 15 で導入した Live Text 機能はカメラのファインダーの中で検出されたテキストを挿入出来ることに気付いた。Live Text は疑いなくクールだが、これ迄、私はその意味ある使用法を思い付かなかった。しかし Paprika と一緒に使えば、料理本からレシピをインポートするのは数分間しかからず、口述するより遙かに少ない時間で出来る。

Live Text を使って "Marinated Kale Salad with Chickpeas and Sumac Onions (ひよこ豆と赤タマネギ入りケールのマリネサラダ)" レシピを J. Kenji Lopez-Alt の The Food Lab からスキャンしたやり方を紹介したいと思う。手書きしたメモも含まれる。

まず最初に Paprika で新しいレシピを作る。それから以下の手順を踏むのだが、その様子は下記のスクリーンショットでも見られる：

1. Name テキストフィールドをあたかもタイプ入力するが如くタップする。
2. 出てきた Scan Text ボタンをタップ。Live Text カメラファインダーが画面の下部にあるキーボードに置き換わる。
3. スキャンしたいテキストをファインダーの中に入るように位置決めする。黄色の印で囲まれていることを確認する。
4. 青色の挿入ボタンをタップ。(そして、いいえ、Apple が何故「挿入」の表示を小文字にしたのか私には分からない。)
5. レシピの残りのフィールドも同じ様に繰り返す：説明、材料、作り方、等々。

コメントとスクリーンショットに触発されたヒントを幾つか。

• このレシピでは、名前は複数の短い行に分かれているが、Live Text はうまく捌いた。レシピの名前だけでなく色々な所で一つの長い行長に直面した場合、上下の余分のテキストを入れる事なしに欲しいテキストだけをファインダーに収めるのは難しい。その様な場合は、必要とする以上のテキストを挿入して、後で余分のものを削除する。
• レシピの名前は全部大文字の場合が多いが、Live Text はそれを保存する。私はそれが気になるので、選択したテキストをタイトルケース (各単語の最初の文字を全て大文字にする) に変換するショートカットを作成した。残念ながら、使うのは多少面倒である。挿入した後で全大文字の名前を変えるには、Name フィールドをタップ、Select All をタップ、共有アイコンをタップ、この Change Case ショートカットをタップ、共有シートを閉じ、選択された状態のテキストをタップ、そして Paste をタップしなければならない。$2.99 の Text Case アプリは共有シートを閉じる必要性を削減するが、それだけの価値があるかは疑問である。TidBITS Talk 読者の Nalarider は、Mac バージョンの Paprika を使えば Keyboard Maestro や他の Mac ユーティリティが使えると指摘している。
  
• Live Text は目的のフィールドに挿入されるべきテキストをプレビュー表示するので、その段階で作業は完了していると勘違いさせる可能性がある。だがそうではなく、プレビュー表示されたテキストをその場所に固定するには青色の Insert ボタンを押さなければならない。私は今でもこの間違いをしでかすことがある。
• Live Text にとって、改行は難題である。時として、不必要な改行を追加することもある；別な場合には、改行されているべきテキストを一緒にしてしまうこともある。どうしようもない間違いではないが、欲しい見た目にするには少々の編集が必要になることもある。
• 材料のリストには ½ の様な分数がしばしば含まれるが、私は Live Text がそれ等を正しく補足しそして挿入したことに感心させられた。Paprika にはよく使われる分数のための特別なショートカットが含まれるが、口述では 1/2 の様な通常の文字しか挿入してくれない。
• 材料リストが二つのコラムに分かれてしまうのは珍しくない。そうなった場合、左側のコラムを、それから右側をスキャンする。両方を一度にスキャンするのでは望んだ結果を生み出さない。左側のコラムをスキャンした後、Ingredients フィールドでその下をタップする。Scan Text ボタンは縮小してただのアイコンになっているのに気付かれるであろう。でも、同じ様に働く。
• Live Text は印刷テキストよりも手書きのものの方が苦手だが、それでも結構良い結果が得られるので、スキャンしたテキストは一旦受け入れておいて後でそれを編集する価値はある。
• スキャン後はレシピ全体に目を通し、Live Text が重大な驚愕を引き起こすような間違いをしていないことを確かめる。例えば、殴り書きした "塩 小さじ ¼ " を "塩 小さじ 4" と解釈すると言うような場合である。"t" と "T" の間違いも同じ様に悪いであろう。私はインポートしたレシピでこの手の間違いは経験したことがないが、間違いは不可避であり、とりわけ手書きのメモの場合は避けがたい。

当然ながら、レシピのテキストをスキャンすることにまつわる特別なことと言えば、多くの人がレシピの大きなコレクションを紙で持っていることである。Live Text はデジタイズしたいどんなアナログテキストに対してもその魔法の効果を発揮するであろう、相手が Paprika の様な専用アプリであろうが或いはテキスト入力を受け入れる如何なるアプリであっても。

皆さんはテキストをスキャンするのに Live Text をどの様に利用したことがありますか？

討論に参加

LastPass CEO の Karim Toubba が、このパスワード管理会社が先月セキュリティ侵害を被り、暗号化されていない顧客アカウントデータと、暗号化されたユーザ名とパスワードを含む顧客ヴォールトを攻撃者が盗み出したと発表した。

これは LastPass にとっては悪夢のような状況かもしれないが、大多数のユーザーはそれほど大きなリスクには瀕していないはずだ。なぜなら、この会社の Zero Knowledge セキュリティ・アーキテクチャがユーザーのマスターパスワードへのアクセスを防ぎ、それを知られないようにしているからだ。つまり、盗まれたデータにマスターパスワードは含まれていない。この安全対策によって、盗まれたユーザ名とパスワードの暗号を攻撃者が解くことが防がれる。

LastPass はこの漏洩に関して以前からある程度透明性を提供し、漏洩が起こった時点でそれを公表するとともに今週になって詳細を追加公表した。LastPass の自社運用プロダクション環境は漏洩していないけれども、攻撃者は 2022 年 8 月にある開発者のアカウントに侵入して入手した情報を利用して別の従業員のアカウントを標的とし、LastPass がバックアップとして使っているクラウドベースのストレージからデータを盗み出したという。(議論の余地はあるが、これらの出来事はすべて一つのセキュリティ侵害の要素であると見なされる。)

このインシデントはセキュリティに対する LastPass のアプローチの弱点を際立たせる。盗まれたデータの中には顧客の暗号化されていないアカウント情報 (名前、アドレス、電話番号、ただしクレジットカード情報は含まれない) と、暗号化された顧客のヴォールトデータが含まれていた。LastPass はユーザ名、パスワード、セキュアメモ、フォームデータなどを 256-bit AES 暗号化で保護しており、それを復号化できるのはユーザーのマスターパスワードから得られる唯一の暗号鍵によってのみだ。しかしながらユーザーのヴォールトの内部にはパスワード項目に付随したウェブサイト URL が暗号化されずに含まれていて、その点は問題だ。

さらに深刻なことに、LastPass はユーザーが選んだマスターパスワードのみに依存して暗号化データを保護している。この会社はパスワードを設定する際の最低要件を引き上げてきたけれども、ユーザーが弱いマスターパスワードを選んだ結果としてクラッキング攻撃を通じてマスターパスワードが推測されてしまう可能性が残る。Apple の iCloud Keychain も、1Password のクラウドベースのストレージも、他のいくつかのソリューションも、デバイスベースの鍵とマスターパスワードあるいはアカウントログインを混ぜて使うことで抵抗力を増すようにしている。攻撃者がヴォールトやアカウントパスワードを破ることに加えて、デバイスを入手してロックを外すことが必要となるからだ。

LastPass ユーザーはどう対応すべきか？

あなたが LastPass のマスターパスワードを LastPass だけで使っていて他で併用しておらず、この会社のデフォルトの設定を使っている限り、現時点で何もする必要はないと LastPass は提言する。(デフォルトの設定では最低 12 文字以上のパスワードを要件とし、パスワード強化アルゴリズム PBKDF2 で反復数を非常に大きく 100,100 としている。)

もしも攻撃を受けたことのある別のサイトであなたがマスターパスワードを再利用していたり、12 文字より少ないパスワードにしたり (決してそんなことをしてはいけない！)、あるいはパスワード強化設定を下げたりしていたならば、ブルートフォース攻撃によって暗号が破られてしまうかもしれない。(長年のユーザーの中にも、PBKDF2 アルゴリズムの設定をずっと低く、500 とか 5000 とかにしていた人たちがいた。チェックする方法の説明はこちら。) もしあなたがそのどれかに該当していたなら、今すぐマスターパスワードを変更して、複数要素の認証をオンにしておこう。(LastPass Authenticator アプリを使うとよい。説明を読みたければ、LastPass サポートポータルページで Features & Tools をクリックしてから Multifactor Authentication をクリックする。)

ヴォールトが盗まれたので、その中のデータは既に盗人の手にあって、あなたがそれを保護することはもはやできない。LastPass は、マスターパスワードをクラックされるリスクを持つ人は保存してあるウェブサイトのパスワードを変更するのがよいと勧めている。まず、あなたに成りすますために使われる可能性のある重要なアカウント、例えば電子メール、携帯電話、ソーシャルメディアなど、それに加えて財務データを含むところから始めよう。心配ならばさらにもっと広範囲にパスワードを変更しよう。(通常ならば、他で使っていない強力なパスワードは一切変更する必要はないのだが、今回はたとえ暗号化された状態であるとしてもあなたの核心的秘密が盗まれたのだから懸念はある。)

弱いマスターパスワードを使っていた人は、まずそれを変更してから、LastPass アカウントで複数要素の認証をオンにしておこう。たとえ馬が小屋から逃げてしまっても、新しい馬を手に入れて小屋のドアをしっかり閉めておくことはできる。あなたのヴォールトの中に保存されたパスワードを更新してからそれを新しい、強力で、他で使っていないパスワードを使って保護しておけば、たとえ将来また漏洩が起こったとしてもあなたがその影響を受ける可能性は低い。

マスターパスワードが強いか弱いかにかかわらず、今後すべての LastPass ユーザーは対象を定めたフィッシング攻撃に特に警戒する必要がある。今回盗まれた LastPass ヴォールトのバックアップではウェブサイト URL が暗号化されていなかったので、フィッシング攻撃者がその暗号化されていないアカウント情報から電子メールアドレスを取り出して攻撃に使うことは容易だからだ。

もしあなたに電子メールかテキストメッセージが届いて、それが何らかのログインページへのリンクを含んでおり、それが正当なものか否かにほんの少しでも疑問があったなら、まずブラウザを使ってそのウェブサイトに直接ナビゲートして、そのサイト上にあるリンクを使ってログインしよう。URL プレビューを信用してはいけない。ページがほとんど見分けがつかないようにドメイン名を偽造するのはあまりにも簡単なことだからだ。クレジットカード関係の警告や、配達追跡の通知のようなものには特に注意しよう。そういうものは普段からフィッシングでよく使われるやり口だし、とりわけホリデーシーズンの間はユーザーを簡単に騙せてしまうものだから。

疑問と懸念

明らかに LastPass は誤りを犯した。それでも、少なくともこの会社は何が起こったかについて透明性を提供している。LastPass がセキュリティについて特別に思慮に欠けていたという感じはしない。今回のことは、何か月もかけて入念に準備された、極めて精緻な多面的攻撃のように思える。まず始めに一人の従業員に絞って攻撃し、それから別の従業員を標的とすることで最終的に膨大なデータが漏洩したという今回の攻撃の仕組みを、あらゆる団体は価値ある教訓として受け取るべきだろう。それでもなお、今回の結末はいくつかの疑問と懸念を提起する。

LastPass ユーザーは別のパスワード管理ソリューションへの乗り換えを考慮すべきか？

その通りだ。理由は二つある。第一に、マスターパスワードに秘密鍵を絡ませることでこの種の盗難に対する保護を提供するというやり方を LastPass が採用していなかったのは問題だ。第二に、今回の攻撃者が盗み出した情報を利用して将来また LastPass のシステムを攻撃するということもあり得るかもしれない。LastPass は一人の従業員のアカウントに侵入された 8 月の漏洩への対応としてシステムの強化を実施したのだったが、11 月の二人目の従業員への攻撃を防ぐことはできなかった。

反対に、私たちの知る限り、LastPass の Zero Knowledge アーキテクチャは今もまだセキュアであるので、もしあなたが自分のマスターパスワードが強力であることに自信があって、かつ LastPass の全体的なアーキテクチャが信頼できると思うならば、心配せずにそのまま使い続けてよいはずだ。

長年 LastPass を主たるソリューションとして使い続けてきた者として (Tonya は 1Password を使っており、私たちはファミリーヴォールトを Tristan と共有している) 私は今回の漏洩だけを理由に他に乗り換えるつもりはない。けれども、私は他の厄介事で LastPass に苛立ちを感じている。複数要素の認証が Apple Watch で使えないこと、生成されるパスワードが記号を含み 20 文字から成るという設定を記憶してくれないこと、それからその Chrome 拡張が頻繁に壊れてしまうこと (2021 年 8 月 24 日の記事“Chrome 拡張が消える？ ならば Repair をクリックしよう”参照) もある。だから、私は時間の余裕が見つかれば 1Password に乗り換えることに決めた。

今回の漏洩はクラウドベースのパスワード管理サービスという考え方そのものへの批判なのか？

この質問にイエスと答える人がいることは間違いないだろう。パスワードをローカルに管理していればどこかの会社に対する攻撃によって影響を受けることはないから、というのがその論拠だ。ただ、ここでの問題点はむしろクラウド上のデータがどのように保護されているかというところにある。LastPass はあなたのデータのための暗号化鍵を保持していないけれども、問題はその暗号化方法が十分には強力でないことだ。暗号の力のすべてがたった一つのマスターパスワードに依存していて、どこにでも入力できるようになっている。複数個のコンポーネントを要求しそれらを別々の場所に保持するようにはしていない。

クラウドベースのストレージを拒否してパスワードをローカルに管理するというやり方は、特定の対象を狙わずランダムに選んだ相手に仕掛けるフィッシングやその他の攻撃の犠牲にならないという前提の上に成り立っている。LastPass の漏洩は特定の従業員を標的とした直接の攻撃であったのだが、相手を定めない手当たり次第の攻撃は自動化されたり、あるいはマルウェアを使って広く配布されたりする。そのような場合、攻撃者は誰が犠牲者なのか知らないし、そんなことを気にも留めない。

その上、クラウドベースのシステムは二つの魅力的な機能を提供する。複数のデバイスやプラットフォームに跨って同期できることと、特定のパスワードを同じシステム上の他のユーザーと共有できることだ。iCloud、Dropbox その他を使えば同期は比較的簡単だが、パスワードを他の人と共有するためには共有アカウントが必要となる。

他のパスワードマネージャもやはり同種の攻撃を受ける恐れがあるのか？

私にはそうは思えない。LastPass での侵害は過去に盗まれた情報に依存していた。個々の従業員を標的とした攻撃で盗み出した認証情報やその他の情報によって補助的なバックアップストレージへのアクセスが提供されてしまったのだ。これはカスタマイズされた攻撃であって、他の会社に対してそのまま使われることはない。それに加えて、LastPass がたった一つのマスターパスワードに依存していたことがユーザーのデータを特別のリスクに晒した。

そうは言っても、あらゆるパスワード管理サービスはほぼ常時攻撃に晒されつつあると考えておかなければならない。なぜなら、有名な銀行強盗 Willie Sutton の言葉を借りれば、そこにパスワードがあるからだ。それらの会社はそのような攻撃をいつものことだと考えるかもしれないが、ひょっとすると LastPass のインシデントから学んで自らのセキュリティ慣行を見直し、何か見落としがないかを調べているところかもしれない。LastPass は、おそらく 2022 年 8 月より以前には見落としがあるとは考えていなかったのだろう。

いつになったらパスキーがこの種の問題を一挙に取り去ってくれるのか？

確かなことは分からないが、すぐに移行が起こる訳ではない。記事“パスキーがパスワードよりシンプルかつセキュアなものになる理由”(2022 年 6 月 27 日) を参照。

討論に参加