パスワードを忘れた? アカウント作成
15445803 story
MacOSX

macOSの暗号化zipファイルはパスワード無しで比較的容易に解凍できる 51

ストーリー by nagazou
解凍 部門より
NFLabsの記事によれば、macOSで作られた暗号化zipファイルは、特定の二つの条件を満たすとパスワード無しで簡単に解凍できるのだそうだ。その条件の一つはzipの暗号化方式がzipcryptoであること、二つ目はzip内のディレクトリの中身が.DS_Storeファイル+何らかのファイルが1個であるといった条件だという(NFLabs)。

細かい仕組みに関しては元記事を見ていただきたいが、結論としてはシステム構成に関する情報が含まれる「.DS_Store」ファイルを利用するもので、zipファイル内の.DS_Storeを既知平文攻撃を外部ツールを利用して行うことにより、暗号化zipファイルをパスワード無しで解凍できるとしている。
  • by Anonymous Coward on 2021年10月12日 6時18分 (#4130350)

    と思って読んだら、なるほど.DS_Storeのパターンが限られているので「既知平文が手に入る」という条件を簡単に満たせてしまうのか

    ここに返信
    • by Anonymous Coward

      「zipcryptが簡単に破れる」ってよく言うけど、パスワードがちょっと長いだけで結構時間掛かるのよね。
      長さや文字種組み合わせに確信がないと心折れるくらいは掛かる。
      だから既知平文攻撃ができるってのは割と強い。

      既知平文攻撃自体は知ってたけどzipcryptでここまで気楽かつ強力とは知らなかった。
      .DS_Storeに限らず既知平文は割合ありがちだからリアルに怖いね。
      個人用途では7zipの暗号化を使ってるからそう心配はないが。

      • 「zipcryptが簡単に破れる」ってよく言うけど、パスワードがちょっと長いだけで結構時間掛かるのよね。

        821日が 64日になる、という計算らしいけど、それほどお手軽では無いとも言えるし。クラウド環境などを動員されたら、そんなに差は無いのかも。

        7z あたりが OS で標準サポートされないのはどうしてなのかな。

        今回の手法で全パターン(65536通り) を総当たりするのにかかる時間は、以下のようになります。 (先程のスクショを取得したのと同じ端末の場合)

        .DS_Store 1パターンあたりにかかる時間 (85秒) * 65536 = 5570560秒 = 92842分 = 1547時間 = 64日

        また、同端末のhashcatのベンチマーク結果 (m=17200) は85915.0 kH/sでした。
        この結果から、英数字+記号の8文字のパスワードをブルートフォースするためにはおよそ以下の時間がかかることがわかります。

        948 / 85915000 = 70950234秒 = 1182503分 = 19708時間 = 821日

        つまり、単純なパスワードの総当たりと比べ、今回の手法は8文字の段階で10倍以上高速であることがわかります。

        • by Anonymous Coward on 2021年10月12日 7時52分 (#4130376)

          7zやrarはzipフォルダーのようなものを実装するのが困難(最後のファイル1つだけがほしくても先頭からすべて展開しなければならない)。圧縮率と引き換えなので一概に悪いとは言えないけど

          • by Anonymous Coward on 2021年10月12日 8時46分 (#4130400)

            それはソリッド形式とよばれるもので、オプションを外せばファイル単位での圧縮も対応していますよ
            ただ書かれている通り、圧縮率はかなり変わってきますが
            7zip や rar が劣るとすれば(辞書サイズなど仕方ないけど)メモリ使用量や処理速度、最適化された実装の存在くらいじゃないかな

            • by Anonymous Coward

              自分で圧縮したファイルだけを扱えればいいわけじゃないからオプションで無効にできても意味がない

              • by Anonymous Coward

                実装が困難という誤解に対し、そういったオプションが既にあるという指摘をしただけで
                入手した圧縮ファイルから 1 ファイルだけ取り出せないから意味がない、ってよくわからん反論だなぁ
                全展開するのが大変な圧縮ファイルから 1 ファイルだけ取り出したい、って割とレアケースなのでは

              • by Anonymous Coward

                前提の、OSの標準として実装って条件が抜けてないかな?
                オプションによって内部の単一ファイルを扱えたり扱えなかったりするんじゃ、標準には使えないでしょ。

              • by Anonymous Coward

                そんな前提は提示されていないのですが……
                OS の標準に不適な理由は #4130430 にもある通りライセンスが理由だと思うけど
                機能的な理由で不適となるなら、オプションが多すぎて初心者には扱いにくいかも、ぐらいかな(ファイル名も暗号化できるのは必要な機能だけど混乱しそう、とか)

                なお可能/不可能の意味で「扱えない」という書き方をしているならこれも誤解で、処理時間がかかるだけで扱えはしますよ
                ある程度モダンな環境(CPU/メモリ/SSD)であれば、それほど違和感なく扱えるような実装には出来るんじゃないかな

              • by Anonymous Coward

                >7z あたりが OS で標準サポートされないのはどうしてなのかな。

              • by Anonymous Coward

                #4130376 が
                > 7z あたりが OS で標準サポートされないのはどうしてなのかな。
                に対する回答であるというならそうかもしれませんが明示もされていませんし、技術的な回答に対しては #4130400 で誤りを指摘しています
                そこに運用上の問題を #4130408 で追加していますが、それに対しても #4130433 でレアケースじゃないかと指摘しているのですが
                追加される後付け理由にも全部回答を提示していて、なお何に疑問を呈されるのか……

          • by Anonymous Coward

            いうて7zipもrarも公式ツールはアーカイブをフォルダのように操作できますし…
            むしろファイルを取り出すときよりファイルを消したり足すときのほうが問題。
            あと単純に遅い。

            • by Anonymous Coward

              一覧を表示するだけならインデックスを見るだけだから速いけど、ファイルを取り出そうとするとわかるよ。少なくとも7-Zipの公式クライアントは

          • by Anonymous Coward

            ランダムアクセス可(先頭から全て展開する必要がない)、認証つき暗号採用、メタデータ(ヘッダー)も暗号化、マルチプラットホーム、となると思い当たるのは rar, ezio, dar ぐらい。

            rar は linux 上で使っても良いモノなんだけどライセンスの問題がどうにもならない。
            個人的には ezio を改造して使っている。erasure code があって extend attribute にも対応しているから linux 上で /etc とかまるっと暗号化バックアップ作るのにちょうどいい感じ。

        • by Anonymous Coward on 2021年10月12日 9時15分 (#4130430)

          既知平文攻撃はパスワードの長さ(強度)を無視できます(結果としてパスワードが不明なまま展開される)
          そのためパスワードを長くすればするほど総当たりとの差は広がる一方で、それが
          > つまり、単純なパスワードの総当たりと比べ、今回の手法は8文字の段階で10倍以上高速であることがわかります。
          という一文に現れています

          > 7z あたりが OS で標準サポートされないのはどうしてなのかな。
          cab があるから、というのと 7z は GNU LPGL なのでライセンス上リバースエンジニアリングの許可が必要など Windows に標準で載せるには縛りが厳しいからではないかな

          • by Anonymous Coward

            > 7z は GNU LPGL なので

            7-ZipはLGPLだけどLZMA SDK [sevenzip.osdn.jp]はpublic domainだよ。7zをサポートするだけならこれで十分なのでライセンスが理由ではない。

        • by Anonymous Coward

          #4130357に書いたけど実際にはさらに数万倍高速化できると思う

        • by Anonymous Coward

          LZMAが赤い赤いロシアのアルゴリズムだから。

          • by Anonymous Coward

            と、中国製の端末を使って書き込んでるんですね

        • by Anonymous Coward

          7z あたりが OS で標準サポートされないのはどうしてなのかな

          自前のフォルダー操作ができて暗号化にも圧縮にも対応したディスクイメージというものがありますので。

        • by Anonymous Coward

          そういえばWindowsに搭載のtarコマンドはlibarchive実装なので、たぶん7zを読み書きできるはず。OSサポートとして思っているのと違うかもしれないけど。

          • by Anonymous Coward

            ところがぎっちょん、Windows標準のtarはわざわざ7-Zipサポートをオフにしてビルドされているらしく、使えない。

      • by Anonymous Coward on 2021年10月12日 6時35分 (#4130356)

        既知平文攻撃の場合、パスワードの長さは関係ないからね。

        zipcryptoの内部状態は96bitしかないので、ある程度以上パスワードが長くなったらパスワードよりも内部状態で総当りしたほうが速くなる。さらにさまざまな攻撃手法で96bit総当たりより大幅に高速化できることが知られており、既知平文攻撃もその1つ。

    • by Anonymous Coward

      https://link.springer.com/chapter/10.1007/3-540-60590-8_12 [springer.com]
      まあ、セキュリティの啓蒙として定期的に話題になる方がいい話ではあるよね。

      • by Anonymous Coward

        お、オープンアクセスなのか

    • by Anonymous Coward

      小さなファイルは大丈夫なのかな。2バイトのファイルが含まれてたら内容は65536通りしかない同じ事ができちゃうけど。さすがにzipcryptの危険性を知ってるからランダムなパディングをくっつけてちょっと水増ししてから圧縮する(解凍時にそこは捨てる)ような仕様にでもなってるのかな?

      • by Anonymous Coward on 2021年10月12日 12時29分 (#4130595)

        > 小さなファイルは大丈夫なのかな。2バイトのファイルが含まれてたら内容は65536通りしかない同じ事ができちゃうけど。

        既知平文攻撃には連続した8バイトを含む13バイト以上の平文が必要なので、2バイトのファイルが含まれていてもそれだけでは既知平文攻撃はできない。ただし非常に短いファイルはCRCからの逆算により解読されて攻撃の手がかりになることは確か。

        > ランダムなパディングをくっつけてちょっと水増ししてから圧縮する(解凍時にそこは捨てる)ような仕様にでもなってるのかな?

        勝手にそんなことしたら非対応のソフトで解凍したときランダムなゴミがついちゃうでしょ。脆弱なのがわかっていても互換性のために変更できないから問題なんだよ。逆に処理の変更が許されるなら中途半端なことをしないでAESを採用すればいい。

        • by Anonymous Coward

          前半はなるほどです。
          後半は、zipの暗号化仕様を決めるときの話を想像してたので、勝手にそんな仕様にしても問題はないでしょう、という話です。後付けで勝手にやり方を変えるという突拍子も無いアイデアは想像してませんでした。

    • by Anonymous Coward

      昔PentiumIIの時代になぜかパスワードを忘れたzipをJFIFで既知平文攻撃したらすぐに開けたなあ

  • by Anonymous Coward on 2021年10月12日 6時48分 (#4130358)

    macOSってそういうもんでしょ

    ここに返信
    • by Anonymous Coward

      Apple様的にはzipは他OSとの互換が目的で、ガチで暗号化したいならディスクイメージ使って欲しいんじゃないかな。

  • Zipに格納されているファイルごとのCRCは平文から算出されるから、CRCから.DS_Storeの候補を大幅に絞り込めてさらに高速化できるんじゃないかな。

    ここに返信
    • 元記事では実際に.DS_Storeを総当りしないで計算時間を見積もっているだけか。

      ZipのCRCは32ビットだから、誕生日パラドックスを考慮しても65536通りしか候補がないならほぼピンポイントで答えを絞り込める。したがって所要時間は

      .DS_Store 1パターンあたりにかかる時間 (85秒)+.DS_Store 1パターンのCRC計算にかかる時間*65536

      数百バイトのファイルのCRC計算なんてほとんど一瞬で終わるから、8文字のパスワードで821日かかるものが、パスワードの長さにかかわらず100秒以内で解読できるようになる。たしかにもはや暗号化などないも同然だな

  • by Anonymous Coward on 2021年10月12日 7時28分 (#4130367)

    ドイツの電文にはたいてい「ハイル・ヒトラー」が入っていたから、暗号解読の手がかりになったやつだな

    ここに返信
    • by Anonymous Coward
      「入るヒトラー」だったのか
    • by Anonymous Coward

      って事はエニグマはECBモードに近いのかな?

      #実際には文字数毎に鍵が自動的に切り替わり、文字を数個おきに入れ替えたり、1日毎に全部の設定を弄ったり、何ならメッセージ毎に設定を変えたそうだが

    • by Anonymous Coward

      一方、産業スパイは「拝承」を探した

  • 辞書があれば攻撃にかかる時間が短縮できるだけなのに、辞書があれば暗号化zipファイルをパスワード無しで解凍できるって言ってるようなものかな?
    .DS_Storeを使えるからってちょっと違うよね。

    ここに返信
    • by Anonymous Coward

      理解に近づきたいなら既知平文攻撃を検索してみろ。

      ・何が入ってるか分からない暗号化zipファイルです
      ・暗号化zipファイルに必ずreadme.txtが入っていて、その内容は必ず「・・・(何か決まった挨拶文、他スレにあるようなハイルヒトラーとか)・・・」という固定の文章だと分かっています。他のファイルの中身は分かりません

      だと、後者の方が圧倒的にパスワードを推測するのに掛かる時間が短くて済む、というzipcrypto方式の弱点。
      .DS_Storeが場合によっては65536通りしか無いので、上記のreadme.txtの代わりにそれを使える、というMacOSの設定ファイルの扱いの弱点。

      • by Anonymous Coward

        > パスワードを推測するのに掛かる時間が短くて済む

        既知平文攻撃を行うときはzipcryptoの内部状態を直接攻撃するので、攻撃成功して暗号化を解除できたけど元のパスワードはわからないということもありうる。内部状態からパスワードの推測を高速化する方法も論文には書かれているけど、解読するだけが目的なら必ずしもパスワードを推測する必要はない。

  • by Anonymous Coward on 2021年10月12日 13時14分 (#4130631)
    これ隠しファイルまで圧縮するソフト使うとdesktop.iniでも同じことが言えない?
    ここに返信
    • by Anonymous Coward

      たぶんそうだけど、desktop.iniが置かれるのはデスクトップやマイドキュメントなど特定のフォルダに限られるので、丸ごと圧縮するケースは発生しづらいと思う

      • by Anonymous Coward

        フォルダーの種類を「全般」に強制するとかのためにフォルダーのカスタマイズをしているとdesktop.iniが生成されるので注意。

  • by Anonymous Coward on 2021年10月12日 14時44分 (#4130701)

    圧縮ファイルってそれぞれヘッダーの書式は決まってるだろうから、そこを既知平文攻撃すれば良くね??と思った

    ここに返信
    • by Anonymous Coward

      なのでsaltをまぶす。
      極端な話、利用者は何を突っ込んでくるかわからんしね。

    • by Anonymous Coward

      Zipのヘッダーはそもそも暗号化されていない。仕様上、暗号化は格納されているファイル単位で行ったり行わなかったり違うパスワードを使ったりできる(使用ツールが対応しているかどうかは別)。

      どうしてもzipcryptで.DS_Storeを格納しなければならないなら、.DS_Storeだけ暗号化しないという対策も可能。どうせCRCからの逆算で瞬時に解読できるのだから暗号化しても意味がないし、他のファイルを解読する手がかりに使われるだけむしろ有害。

      • by Anonymous Coward

        >.DS_Storeだけ暗号化しないという対策も可能。

        実際、それがAppleのできる一番現実的な対策になる気がしてきた。

        • by Anonymous Coward

          カレントディレクトリのドットファイルにメタ情報を記録するなんていう、ダサい仕様を止めればいいだけだろうに。

typodupeerror

※ただしPHPを除く -- あるAdmin

読み込み中...