macOSの暗号化zipファイルはパスワード無しで比較的容易に解凍できる 51
ストーリー by nagazou
解凍 部門より
解凍 部門より
NFLabsの記事によれば、macOSで作られた暗号化zipファイルは、特定の二つの条件を満たすとパスワード無しで簡単に解凍できるのだそうだ。その条件の一つはzipの暗号化方式がzipcryptoであること、二つ目はzip内のディレクトリの中身が.DS_Storeファイル＋何らかのファイルが1個であるといった条件だという（NFLabs）。
細かい仕組みに関しては元記事を見ていただきたいが、結論としてはシステム構成に関する情報が含まれる「.DS_Store」ファイルを利用するもので、zipファイル内の.DS_Storeを既知平文攻撃を外部ツールを利用して行うことにより、暗号化zipファイルをパスワード無しで解凍できるとしている。
細かい仕組みに関しては元記事を見ていただきたいが、結論としてはシステム構成に関する情報が含まれる「.DS_Store」ファイルを利用するもので、zipファイル内の.DS_Storeを既知平文攻撃を外部ツールを利用して行うことにより、暗号化zipファイルをパスワード無しで解凍できるとしている。
zipcryptが簡単に破れるって話の何が新しいの? (スコア:1)
と思って読んだら、なるほど.DS_Storeのパターンが限られているので「既知平文が手に入る」という条件を簡単に満たせてしまうのか
Re: (スコア:0)
「zipcryptが簡単に破れる」ってよく言うけど、パスワードがちょっと長いだけで結構時間掛かるのよね。
長さや文字種組み合わせに確信がないと心折れるくらいは掛かる。
だから既知平文攻撃ができるってのは割と強い。
既知平文攻撃自体は知ってたけどzipcryptでここまで気楽かつ強力とは知らなかった。
.DS_Storeに限らず既知平文は割合ありがちだからリアルに怖いね。
個人用途では7zipの暗号化を使ってるからそう心配はないが。
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:2)
「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倍以上高速であることがわかります。
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:1)
7zやrarはzipフォルダーのようなものを実装するのが困難(最後のファイル1つだけがほしくても先頭からすべて展開しなければならない)。圧縮率と引き換えなので一概に悪いとは言えないけど
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:2, 参考になる)
それはソリッド形式とよばれるもので、オプションを外せばファイル単位での圧縮も対応していますよ
ただ書かれている通り、圧縮率はかなり変わってきますが
7zip や rar が劣るとすれば（辞書サイズなど仕方ないけど）メモリ使用量や処理速度、最適化された実装の存在くらいじゃないかな
Re: (スコア:0)
自分で圧縮したファイルだけを扱えればいいわけじゃないからオプションで無効にできても意味がない
Re: (スコア:0)
実装が困難という誤解に対し、そういったオプションが既にあるという指摘をしただけで
入手した圧縮ファイルから 1 ファイルだけ取り出せないから意味がない、ってよくわからん反論だなぁ
全展開するのが大変な圧縮ファイルから 1 ファイルだけ取り出したい、って割とレアケースなのでは
Re: (スコア:0)
前提の、OSの標準として実装って条件が抜けてないかな？
オプションによって内部の単一ファイルを扱えたり扱えなかったりするんじゃ、標準には使えないでしょ。
Re: (スコア:0)
そんな前提は提示されていないのですが……
OS の標準に不適な理由は #4130430 にもある通りライセンスが理由だと思うけど
機能的な理由で不適となるなら、オプションが多すぎて初心者には扱いにくいかも、ぐらいかな（ファイル名も暗号化できるのは必要な機能だけど混乱しそう、とか）
なお可能/不可能の意味で「扱えない」という書き方をしているならこれも誤解で、処理時間がかかるだけで扱えはしますよ
ある程度モダンな環境（CPU/メモリ/SSD）であれば、それほど違和感なく扱えるような実装には出来るんじゃないかな
Re: (スコア:0)
>7z あたりが OS で標準サポートされないのはどうしてなのかな。
Re: (スコア:0)
#4130376 が
> 7z あたりが OS で標準サポートされないのはどうしてなのかな。
に対する回答であるというならそうかもしれませんが明示もされていませんし、技術的な回答に対しては #4130400 で誤りを指摘しています
そこに運用上の問題を #4130408 で追加していますが、それに対しても #4130433 でレアケースじゃないかと指摘しているのですが
追加される後付け理由にも全部回答を提示していて、なお何に疑問を呈されるのか……
Re: (スコア:0)
いうて7zipもrarも公式ツールはアーカイブをフォルダのように操作できますし…
むしろファイルを取り出すときよりファイルを消したり足すときのほうが問題。
あと単純に遅い。
Re: (スコア:0)
一覧を表示するだけならインデックスを見るだけだから速いけど、ファイルを取り出そうとするとわかるよ。少なくとも7-Zipの公式クライアントは
Re: (スコア:0)
ランダムアクセス可(先頭から全て展開する必要がない)、認証つき暗号採用、メタデータ(ヘッダー)も暗号化、マルチプラットホーム、となると思い当たるのは rar, ezio, dar ぐらい。
rar は linux 上で使っても良いモノなんだけどライセンスの問題がどうにもならない。
個人的には ezio を改造して使っている。erasure code があって extend attribute にも対応しているから linux 上で /etc とかまるっと暗号化バックアップ作るのにちょうどいい感じ。
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:1)
既知平文攻撃はパスワードの長さ（強度）を無視できます（結果としてパスワードが不明なまま展開される）
そのためパスワードを長くすればするほど総当たりとの差は広がる一方で、それが
> つまり、単純なパスワードの総当たりと比べ、今回の手法は8文字の段階で10倍以上高速であることがわかります。
という一文に現れています
> 7z あたりが OS で標準サポートされないのはどうしてなのかな。
cab があるから、というのと 7z は GNU LPGL なのでライセンス上リバースエンジニアリングの許可が必要など Windows に標準で載せるには縛りが厳しいからではないかな
Re: (スコア:0)
> 7z は GNU LPGL なので
7-ZipはLGPLだけどLZMA SDK [sevenzip.osdn.jp]はpublic domainだよ。7zをサポートするだけならこれで十分なのでライセンスが理由ではない。
Re: (スコア:0)
#4130357に書いたけど実際にはさらに数万倍高速化できると思う
Re: (スコア:0)
LZMAが赤い赤いロシアのアルゴリズムだから。
Re: (スコア:0)
と、中国製の端末を使って書き込んでるんですね
Re: (スコア:0)
7z あたりが OS で標準サポートされないのはどうしてなのかな
自前のフォルダー操作ができて暗号化にも圧縮にも対応したディスクイメージというものがありますので。
Re: (スコア:0)
そういえばWindowsに搭載のtarコマンドはlibarchive実装なので、たぶん7zを読み書きできるはず。OSサポートとして思っているのと違うかもしれないけど。
Re: (スコア:0)
ところがぎっちょん、Windows標準のtarはわざわざ7-Zipサポートをオフにしてビルドされているらしく、使えない。
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:1)
既知平文攻撃の場合、パスワードの長さは関係ないからね。
zipcryptoの内部状態は96bitしかないので、ある程度以上パスワードが長くなったらパスワードよりも内部状態で総当りしたほうが速くなる。さらにさまざまな攻撃手法で96bit総当たりより大幅に高速化できることが知られており、既知平文攻撃もその1つ。
Re: (スコア:0)
https://link.springer.com/chapter/10.1007/3-540-60590-8_12 [springer.com]
まあ、セキュリティの啓蒙として定期的に話題になる方がいい話ではあるよね。
Re: (スコア:0)
お、オープンアクセスなのか
Re: (スコア:0)
小さなファイルは大丈夫なのかな。2バイトのファイルが含まれてたら内容は65536通りしかない同じ事ができちゃうけど。さすがにzipcryptの危険性を知ってるからランダムなパディングをくっつけてちょっと水増ししてから圧縮する(解凍時にそこは捨てる)ような仕様にでもなってるのかな?
Re:zipcryptが簡単に破れるって話の何が新しいの? (スコア:1)
> 小さなファイルは大丈夫なのかな。2バイトのファイルが含まれてたら内容は65536通りしかない同じ事ができちゃうけど。
既知平文攻撃には連続した8バイトを含む13バイト以上の平文が必要なので、2バイトのファイルが含まれていてもそれだけでは既知平文攻撃はできない。ただし非常に短いファイルはCRCからの逆算により解読されて攻撃の手がかりになることは確か。
> ランダムなパディングをくっつけてちょっと水増ししてから圧縮する(解凍時にそこは捨てる)ような仕様にでもなってるのかな?
勝手にそんなことしたら非対応のソフトで解凍したときランダムなゴミがついちゃうでしょ。脆弱なのがわかっていても互換性のために変更できないから問題なんだよ。逆に処理の変更が許されるなら中途半端なことをしないでAESを採用すればいい。
Re: (スコア:0)
前半はなるほどです。
後半は、zipの暗号化仕様を決めるときの話を想像してたので、勝手にそんな仕様にしても問題はないでしょう、という話です。後付けで勝手にやり方を変えるという突拍子も無いアイデアは想像してませんでした。
Re: (スコア:0)
昔PentiumIIの時代になぜかパスワードを忘れたzipをJFIFで既知平文攻撃したらすぐに開けたなあ
知ってた (スコア:1)
macOSってそういうもんでしょ
Re: (スコア:0)
Apple様的にはzipは他OSとの互換が目的で、ガチで暗号化したいならディスクイメージ使って欲しいんじゃないかな。
単純に.DS_Store総当りで既知平文攻撃を試みているようだけど (スコア:0)
Zipに格納されているファイルごとのCRCは平文から算出されるから、CRCから.DS_Storeの候補を大幅に絞り込めてさらに高速化できるんじゃないかな。
Re:単純に.DS_Store総当りで既知平文攻撃を試みているようだけど (スコア:1)
元記事では実際に.DS_Storeを総当りしないで計算時間を見積もっているだけか。
ZipのCRCは32ビットだから、誕生日パラドックスを考慮しても65536通りしか候補がないならほぼピンポイントで答えを絞り込める。したがって所要時間は
.DS_Store 1パターンあたりにかかる時間 (85秒)+.DS_Store 1パターンのCRC計算にかかる時間*65536
数百バイトのファイルのCRC計算なんてほとんど一瞬で終わるから、8文字のパスワードで821日かかるものが、パスワードの長さにかかわらず100秒以内で解読できるようになる。たしかにもはや暗号化などないも同然だな
エニグマ暗号 (スコア:0)
ドイツの電文にはたいてい「ハイル・ヒトラー」が入っていたから、暗号解読の手がかりになったやつだな
Re: (スコア:0)
Re: (スコア:0)
って事はエニグマはECBモードに近いのかな？
#実際には文字数毎に鍵が自動的に切り替わり、文字を数個おきに入れ替えたり、1日毎に全部の設定を弄ったり、何ならメッセージ毎に設定を変えたそうだが
Re: (スコア:0)
一方、産業スパイは「拝承」を探した
暗号化zipファイルをパスワード無しで解凍できる？？ (スコア:0)
辞書があれば攻撃にかかる時間が短縮できるだけなのに、辞書があれば暗号化zipファイルをパスワード無しで解凍できるって言ってるようなものかな？
.DS_Storeを使えるからってちょっと違うよね。
Re: (スコア:0)
理解に近づきたいなら既知平文攻撃を検索してみろ。
・何が入ってるか分からない暗号化zipファイルです
・暗号化zipファイルに必ずreadme.txtが入っていて、その内容は必ず「・・・(何か決まった挨拶文、他スレにあるようなハイルヒトラーとか)・・・」という固定の文章だと分かっています。他のファイルの中身は分かりません
だと、後者の方が圧倒的にパスワードを推測するのに掛かる時間が短くて済む、というzipcrypto方式の弱点。
.DS_Storeが場合によっては65536通りしか無いので、上記のreadme.txtの代わりにそれを使える、というMacOSの設定ファイルの扱いの弱点。
Re: (スコア:0)
> パスワードを推測するのに掛かる時間が短くて済む
既知平文攻撃を行うときはzipcryptoの内部状態を直接攻撃するので、攻撃成功して暗号化を解除できたけど元のパスワードはわからないということもありうる。内部状態からパスワードの推測を高速化する方法も論文には書かれているけど、解読するだけが目的なら必ずしもパスワードを推測する必要はない。
windowsでも起こり得る？ (スコア:0)
Re: (スコア:0)
たぶんそうだけど、desktop.iniが置かれるのはデスクトップやマイドキュメントなど特定のフォルダに限られるので、丸ごと圧縮するケースは発生しづらいと思う
Re: (スコア:0)
フォルダーの種類を「全般」に強制するとかのためにフォルダーのカスタマイズをしているとdesktop.iniが生成されるので注意。
ぶっちゃけzipに限らず (スコア:0)
圧縮ファイルってそれぞれヘッダーの書式は決まってるだろうから、そこを既知平文攻撃すれば良くね？？と思った
Re: (スコア:0)
なのでsaltをまぶす。
極端な話、利用者は何を突っ込んでくるかわからんしね。
Re: (スコア:0)
Zipのヘッダーはそもそも暗号化されていない。仕様上、暗号化は格納されているファイル単位で行ったり行わなかったり違うパスワードを使ったりできる(使用ツールが対応しているかどうかは別)。
どうしてもzipcryptで.DS_Storeを格納しなければならないなら、.DS_Storeだけ暗号化しないという対策も可能。どうせCRCからの逆算で瞬時に解読できるのだから暗号化しても意味がないし、他のファイルを解読する手がかりに使われるだけむしろ有害。
Re: (スコア:0)
＞.DS_Storeだけ暗号化しないという対策も可能。
実際、それがAppleのできる一番現実的な対策になる気がしてきた。
Re: (スコア:0)
カレントディレクトリのドットファイルにメタ情報を記録するなんていう、ダサい仕様を止めればいいだけだろうに。
Re: (スコア:0)
MediaID.bin「そうだそうだ」