Mac OS X Lionでは一般ユーザーでもshadow化されたパスワードにアクセスできる 73
ストーリー by hylom
どうしてこうなった 部門より
どうしてこうなった 部門より
insiderman 曰く、
yebo blogによると、Mac OS X 10.7 Lionでは、一般ユーザーでもshadow化されたユーザーのパスワードにアクセスできてしまうそうだ。
shadow化というのは、ハッシュ化されたパスワードを特権ユーザー以外には見えないようにすることで保護する仕組み。Mac OS XではLinuxなどのように/etc/shadowファイルにハッシュを保存するのではなく、ディレクトリサービスのデータベース内に保存されているのだが、一般ユーザーでもディレクトリサービスにアクセスするコマンド（dscl）を使ってパスワードのハッシュを読むことができるとのこと。10.6以前では一般ユーザーではアクセスできなかったが、10.7でこのように変更されたそうだ。
パスワードが直接閲覧できるわけではないが、ハッシュを読まれてしまうと総当たり攻撃などによってパスワードを解読されてしまう可能性がある。
自分のパスワードを入力せず変更できちゃう件も (スコア:5, 興味深い)
同時に報告されているように、自分のパスワード変更の際
旧パスワードの入力が不要だという問題もあります。
http://nakedsecurity.sophos.com/2011/09/20/flaw-in-os-x-lion-allows-un... [sophos.com]
つまり、dsclなんちゃら～というコマンドを
何らかの方法で踏まされてしまうと、一発で
もうログインできなくなってしまうわけですね。
もしディスク暗号化なんかしてあったら
データがすべて失われてしまうことになりかねない
とも書いてあります。
こっちも小さい問題ではないと思いますので
オフトピ覚悟で書きました。
Re:自分のパスワードを入力せず変更できちゃう件も (スコア:1)
つまり、dsclなんちゃら～というコマンドを 何らかの方法で踏まされてしまうと、一発で もうログインできなくなってしまうわけですね。
もしディスク暗号化なんかしてあったら データがすべて失われてしまうことになりかねない とも書いてあります。
そうなったら、ゲストアカウントでログインして dscl でパスワードのハッシュを読みだして、辞書とかレインボーテーブルとか総当たり攻撃をすれば、いつかは...
Re: (スコア:0)
えっｗ
小さい問題でないどころか、こっちのほうが「ただちに」問題がおきるような。
shadowのほうにしろ、こっちにしろ、普通に今まで通りにしておけば
こうはならないわけで、わざわざこういう仕様にしたのか、ミスなのかなんなんだろう。
Re: (スコア:0)
枝野経産相「Macを知らない人に触らせなれければよいので、直ちに問題はありません。」
Re: (スコア:0)
枝野のその発言、日本語分からない人が誤読しまくってるので一応マジレスしておくけど、「ただちに問題は無い」=「少なくとも年単位で蓄積した後でなければ、短期的にも長期的にも影響は出ない」の意味だからね。
Macは今すぐ問題。
Re: (スコア:0)
誤読では無いと思いますが
前後の言葉も含めて、本人がそういった意味で使ったわけではないということだったのでは？
単に「ただちに」には、そういった意味は無いみたいですが・・・
Re: (スコア:0)
「将来的にも影響は無い」と付け加えてるんだけどな。
shadowの意味を再定義 (スコア:1)
またAppleが一つイノベーションを起こしてしまったか
大変だ (スコア:1)
一般人がシャドーの情報にアクセスできるなんてストレイカー大佐も頭が痛いだろうな。
らじゃったのだ
Re:大変だ (スコア:1)
それは驚いた。 (スコア:0)
> パスワードが直接閲覧できるわけではないが、ハッシュを読まれてしまうと総当たり攻撃などによってパスワードを解読されてしまう可能性がある。
可能性を言い出したらキリが無いわけですが。
Re:それは驚いた。 (スコア:2)
そういうわけなので、対策の一つとしてゲストアカウントを無効にしておきましょう、というお話では。
後は基本として短いパスワードは付けない。
そのうち修正されると思いますが。
Re:それは驚いた。 (スコア:1)
お安い GPU で強固なパスワードも用無しに [srad.jp]
ハッシュが漏れた場合の総当たりはすでに十分現実的ですよ。
#2022222 のAC であるが。（was:Re:それは驚いた。 (スコア:1)
ツリーが無駄にのびているようだが、別に釣りではないので言いたかったことを少しまとめてみる。
# というか、こういう洒落すら通じないほどハイレベルな場所になってしまったのか（汗。
では、もう少し引用を短くしてみよう。
＞ハッシュを読まれてしまうと総当たり攻撃などによってパスワードを解
ハッシュを読むこと、と、BFA (総当り)に、何の関係があるんだい？
このケースのBFA に必要なのはハッシュではなく、ユーザ名であって、
ハッシュによって少し楽になるのはDA (辞書攻撃)ではないかのな？
もちろん、可能性を可能な限り排除する、という考え方には賛成するものだけれども、
shadow 化によってBFA を完全に防げる、または、暗号化によって安全を確実に担保できるソリューションが
もし、存在するのであれば、私の後学のために、是非とも教えて欲しい。
また、断言するけれども、このダウングレードによってOSX のEAL [wikipedia.org]が取り消し、またはダウングレードする可能性は0 だろう。
念のため繰り返すけれども、編集を弄っていたのであって、釣りではない。
Re:#2022222 のAC であるが。（was:Re:それは驚いた。 (スコア:2)
1. たまたまログイン状態で席を離れた誰かのMacからその人のパスワードのハッシュを盗ってくる
2. 家に帰って、自分のMacのパスワードテーブルのハッシュを、盗ってきたハッシュに書き換える
3. ログインが成功するまでゆっくりのんびり総当たりでパスワードを試す
4. 1の人のパスワードが分かる
2022222 さんが勘違いをされてるとしたら、「総当たり攻撃」=「2～3の工程を被害者の人のMacで試す事」と思い込んでらっしゃる辺り。それは、時間はかかるわ怪しい痕跡は残るわだから、他の方法で防ぎようがある。
そんなモロバレの間抜けな方法を使わず、↑みたいなバレにくい方法でも総当たり攻撃は可能なのでハッシュを盗られるのは危険。もちろん、↑も果てしなく間抜けなので、まともなプログラマならもうちょっとマシなパスワード解析方法を使う。わざわざログインを試さなくても、OSがパスワードとハッシュの一致を試す方法は広く知られてるので、その部分だけ繰り返し計算するプログラムを書けばよろしい。
ので、タレコミ文の、
>パスワードが直接閲覧できるわけではないが、ハッシュを読まれてしまうと総当たり攻撃などによってパスワードを解読されてしまう可能性がある。
は、「パスワードそのものを盗られた場合と違って、その瞬間から悪用されるものではない」、「盗ったのが悪意と熱意のある人間であればいずれ何らかの攻撃を受けうる」、「弱いパスワードだと辞書攻撃でその『いずれ』が早まりうる」と、ツッコミ所も弄り所も特にない適切なまとめ。
# なんか自分のidに似てたのでツッコミを禁じ得なかった。
Re:#2022222 のAC であるが。（was:Re:それは驚いた。 (スコア:1)
完全ではないにしても、たとえば5回ミスしたらロックとか、n回目以降はwaitが入るとか普通にあるんじゃない?
で、パスワードをBFAするに現実的な時間で完了しないなら、それは解決策なんじゃないかな?
あくまでアカウントリスト取得からBFAだけの視点で。
で、ハッシュがとれるとですが、BFAするにして(つまりDAできないランダムで長いパスワードだったとして)もRainbowテーブルとの突き合せができるので、上記を回避しつつクラックすると。
# たしかに皮肉というか洒落はあったと思うけど、要点は総当りより折角読めない位置にあるはずのshadow=ハッシュが素で読める点が重要だったから、重視されなかった、かなぁ?
という感想をえたのですが、どんなもんでしょう?
M-FalconSky (暑いか寒い)
Re:#2022222 のAC であるが。（was:Re:それは驚いた。 (スコア:1)
ぶ、追記
> たとえば5回ミスしたらロックとか、n回目以降はwaitが入るとか普通にあるんじゃない?
Mac OS Xに限らないで、一般的な防御方法という意味でよろしくorz
M-FalconSky (暑いか寒い)
Re: (スコア:0)
しかも、Shadowを狙えばOSの認証系セキュリティログに残らないのでユーザー・管理者に気づかれないというメリットも。
Re: (スコア:0)
>もちろん、可能性を可能な限り排除する、という考え方には賛成するものだけれども、
>shadow 化によってBFA を完全に防げる、または、暗号化によって安全を確実に担保できるソリューションが
>もし、存在するのであれば、私の後学のために、是非とも教えて欲しい。
「完璧じゃないなら一切意味がない」なんてのは典型的な極論ですね。
たいていは自分の過ちを認めないための逃げ口上です。
Re: (スコア:0)
shadowの意味が分からない馬鹿なんで懇切丁寧に理解できるまで解説していただけますか？
Re: (スコア:0)
Re: (スコア:0)
攻撃者のローカル側で総当りを試せるので、認証失敗時のアカウントロック等で総当り攻撃を制限する方法の意味がなくなるといったところでしょうか。
単純にハッシュの強度に依存することになるので、今後のプロセッサ技術の進歩により、セキュリティが弱くなる可能性がありそうです。
Re: (スコア:0)
shadowなんて取られたら分散処理でいくらでも並列化して辞書攻撃できますから
Re: (スコア:0)
Pentium Proでjohn the ripperぶん回してた頃を思い出す
最近はSHA-512とかだろうから分散なりしないと無理だろね
Re:それは驚いた。 (スコア:1, 参考になる)
Re: (スコア:0)
この記事についての検証じゃないですかw
仕事早すぎ
Re: (スコア:0)
その記事の前半部分は，このストーリとは独立した話題と考えた方がよさそうです。元ネタとなっている
http://www.defenceindepth.net/2009/12/cracking-os-x-passwords.html [defenceindepth.net]
は 2009年12月時点のもので，ハッシュ値の取得には root 権限が必要です。
このストーリの元ネタになっている
http://www.defenceindepth.net/2011/09/cracking-os-x-lion-passwords.html [defenceindepth.net]
では，SHA-512 の場合で解説されていますが，ShadowHashData の冒頭に
Re: (スコア:0)
ローカルで総当たり・・・つまりハードウェアを盗んでじっくりパスワードの解読が出来るってこと？
まずローカルにアクセス出来るってことは・・・セキュリティ的にはあれだがw
管理者権限でいつもログインしている自分は関係ないかwww
Re:それは驚いた。 (スコア:2, 興味深い)
ハードウェア盗まなくても、Webアプリに穴があったり、PHPスクリプトやCGIを他者が設置できたりしたら、管理者権限なくとも、パスワードハッシュを取得されちゃう可能性があるということです(最悪リモートからも)。そして、取得されちゃったハッシュは「攻撃者のローカルなコンピュータ」で気の済むまで解析されちゃう可能性があるってことです。
今だから白状するけど、昔NEXTSTEPのNetinfoシステムも、デフォルトの設定だとリモートからアクセスできて、パスワードハッシュが取れたことがありました。ファイヤーウォールがないと、スコーンとアクセスできちゃいました。で、クラックコードはしらせたら、短いパスワードは解析できちゃってビビッた覚えがあります。
Re: (スコア:0)
＞Webアプリに穴があったり、PHPスクリプトやCGIを他者が設置できたりしたら、管理者権限なくとも、パスワードハッシュを取得されちゃう可能性がある
そりゃそうだけどさ、大きな穴があいているのにわざわざハッシュを盗む奇特な人って・・・
そんな馬鹿なWebアプリ作るような場合は、もっと大きな穴があるだろうと思うよ。
まぁマルウェアなどと組み合わせて、多くのMacからハッシュを集めるようなことでも・・・そんなに大量のハッシュだと解析するのに時間がかかって意味ないかw
Re: (スコア:0)
>そりゃそうだけどさ、大きな穴があいているのにわざわざハッシュを盗む奇特な人って・・・
>そんな馬鹿なWebアプリ作るような場合は、もっと大きな穴があるだろうと思うよ。
そんな単純な話で済んだら、ネットセキュリティの世界は平和になるんだろうなあ。
無知って本人だけは幸せでいいですよね。
>まぁマルウェアなどと組み合わせて、多くのMacからハッシュを集めるようなことでも・・・
>そんなに大量のハッシュだと解析するのに時間がかかって意味ないかw
マルウェアで解析までさせちゃうんじゃないの？
解析済みのパスワードをせっせと外部サーバに送信して、外部から侵入し
Re:それは驚いた。 (スコア:1)
まあそこまで侵入できたら、ブラウザが覚えてるパスワードを狙った方が早そうだけど。
Re: (スコア:0)
○ パスワードを解読されてしまう蓋然性が少なくない。
Re: (スコア:0)
もともと/etc/password ファイルには暗号化されたパスワードが格納されていて、そしてpasswdファイルは誰でも読めるようになっていました、というか今でもそうです。
でもそれでは解析し放題だから、passwd ファイルにはダミーのパスワード'x'とでも入れておいて、一般ユーザには読めないshadowファイルに記録するようにしましょうというのが事の起こりだったと記憶しております。
そもそもpasswdファイルを一般ユーザが読めないようにしなかったのは、そこからユーザ一覧を取得して処理するプログラムでもあったのでしょうか。
なんか負の遺産ぽい気もしますが、次バージョンのMac OS Xではパスワードのハッシュを取得できる(rootにしか見えない)エントリが出来て今までのエントリにはダミーの値しか入らないようになったりして？
Re:それは驚いた。 (スコア:3, 参考になる)
/etc/passwd を読み込んで処理するプログラムはUNIXライクなシステムなら現役で
多数存在しています。
passwd という名前ながら、ユーザIDと
* ユーザ名
* プライマリグループ
* ホームディレクトリ
* ログインシェル
といった情報とのマッピング情報を格納しているので、一般ユーザが /etc/passwd を
読めなくなると、結構な数のプログラムがまともに動作しなくなります。
ためしに chmod 600 /etc/passwd すると ls -l の出力のユーザ名や ps や top で
表示されるはずのユーザ名が数字になってしまうのを確認できるはず。
Re: (スコア:0)
いろんなコメントがついているが。
総当りで解かれるということは、既に逆引き辞書が作られているということだぞ。
passwd見てから、おもむろに総当りで破ろうとするわけではないぞ。
わかった上での議論と思うが、念のため。
クラッカーの思考をシミュレーションしてみる（Re:それは驚いた。 (スコア:1)
総当たり攻撃するだけなら、都度生成すれば済むんではないですか？
どうせ、2^ハッシュのビット数文の都度生成で済むんだし。
今時のCPUやGPUをつかったら、非実用的な時間でもないでしょう。
勿論その前に、既に解明されてるハッシュの一覧辞書やよく使われるキーワードの組み合わせから作成したハッシュ辞書でパターンマッチングして、どれにも一致しないのだけ総当たりに掛けて潰せば良い。
# で、とけたら、「既に解明されてるハッシュの一覧辞書」に追加(´ー｀)y-~
そして、その手の辞書はアングラワールドには掃いて捨てるほど流通してる。脆弱なキーワード一覧から、具体的な乱数パスワードまで。
ハッシュの生成／認証構造がMac独自？ならば、認証機構関連をリバースエンジニアリングして、そこらに転がってるGNU/LinuxやWindowsで動くようなクローンやクラッキングユニットを作れば良い。
所詮、相手がOTPとか外部のワンタイムトークンに依存してない以上、それはそう難しくない（それをやり慣れてる人にとっては）
まぁ、CPUとかGPUの資源だけが欲しければ十万弱で相当高速な物が手にはいる時代だし、その手のソフト専用に機械を廻しても、得られる経済的対価が大きく勝るのならばやる奴は少なからずいる。
（そして、自分でカード喰うにしてもゾンビマシンを作ってさらなる悪事の踏み台を作るにしても、ただ単純にそこらへんのマフィアに売っぱらうにしても、大きな経済的対価が見込める世界みたいですし）
Re: (スコア:0)
言いたいことが良くわからないが、総当りの範囲を辞書にしようとしても現実的じゃないサイズになる。TとかPとかEとか。だから総当りで試すわけ。
辞書なんてのは極々々一部なんだけど、それで数割とかいうレベルで当たるから使われる。
しかしそれから漏れてたらどうしようもないから、あとはおもむろに総当りしかない。
Re:それは驚いた。（オフトピ） (スコア:0)
がっくり来てしまうんだよな。
そもそも (スコア:0)
なんで、こんなことになったんだ？
強化されるならともかく。
Re: (スコア:0)
Re: (スコア:0)
LDAP で認証をやろうと思ったときになんだかすっごく面倒だった覚えがあります。
NSS には渡すんだけど任意のユーザからは見えちゃいけないし、あれ、どうやるんだったっけ?
まあそういうわけで、動くことを優先して安全を置き去りにするのはよくあることです。
Re: (スコア:0)
大半のMacユーザは別にshadowファイルのセキュリティなんて気にしないんじゃない？
マシンのユーザ=マシンの所有者、ってのが普通で一般ユーザのクラックなんてあんまり気にしないのだと思う。
目的 (スコア:0)
ユーザーがどのあたりを歓迎しているのかAppleとしてアンケートしてる状態なんじゃない？
あえて危険性を作ることで (スコア:0)
情報セキュリティへの意識をユーザーに喚起させる。
素晴らしい作戦だと思います。
難点は、そのアプローチが失敗に終わることをWIndowsが証明していることです。
Mac MiniをWeb&DBとして運用する場合のアドバイスを希望 (スコア:0)
せっかくLionがらみでセキュリティ話が出たので、ついでに質問させてください。
Lionをサーバとして運用する場合に、気をつけたほうがよいのはどのあたりでしょうか？
＃システム壊れても、すぐに現状復帰できるようTime Machine頼みでいいのかとか。なんでもよいので。
開けるポートはWebとDB系の二つだけなのですが、
そうすると、できることは、開けるポートを絞って、サービスに不具合が出ないよう祈りながら、
できるだけバックアップとアップデートを繰り返すしかないような。
プログラムに致命的なセキュリティホールがないことが前提ですが。。
＃Mac Miniってお値段も消費電力もお手頃で、個人で運用するサーバとしてはなかなか良いスペックだと思ったんですよね。
＃中身をLinuxやBSD系に入れ替えて運用している人が多いのかもしれませんが。
Re:Mac MiniをWeb&DBとして運用する場合のアドバイスを希望 (スコア:2)
> 開けるポートはWebとDB系の二つだけなのですが、
とりあえず、DB系は IP アドレスなどの制限を付けて、グローバルには開けないようにしましょう。
あと、今回はユーザ権限に関係してるので、個人のホームページのようなものは公開しないようにするとかですかね。
ま、言い出したらキリがないけど。
Re: (スコア:0)
ぶっ壊れた時分解修理が面倒くさい
とか？
Re:Mac MiniをWeb&DBとして運用する場合のアドバイスを希望 (スコア:1)
修理とか面倒やらんで安いんだから入れ替えでいいんじゃねぇかな？
でもって、Apple careとかに投げるとね。
Re:一方Fedora15は (スコア:1)
ざっくり調べてみた。昔のunixでは、rootであればr/wは常に可能、xは少なくともどこかのxビットが立っていれば可、というものだったような覚えだが、いまのLinuxではCAP_DAC_OVERRIDEというケーパビリティがあれば前記の動作をするようだ。
ACLとかなんとかは識者にまかせた