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

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でこのように変更されたそうだ。

パスワードが直接閲覧できるわけではないが、ハッシュを読まれてしまうと総当たり攻撃などによってパスワードを解読されてしまう可能性がある。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 同時に報告されているように、自分のパスワード変更の際
    旧パスワードの入力が不要だという問題もあります。
    http://nakedsecurity.sophos.com/2011/09/20/flaw-in-os-x-lion-allows-un... [sophos.com]

    つまり、dsclなんちゃら~というコマンドを
    何らかの方法で踏まされてしまうと、一発で
    もうログインできなくなってしまうわけですね。

    もしディスク暗号化なんかしてあったら
    データがすべて失われてしまうことになりかねない
    とも書いてあります。

    こっちも小さい問題ではないと思いますので
    オフトピ覚悟で書きました。

    • つまり、dsclなんちゃら~というコマンドを 何らかの方法で踏まされてしまうと、一発で もうログインできなくなってしまうわけですね。

      もしディスク暗号化なんかしてあったら データがすべて失われてしまうことになりかねない とも書いてあります。

      そうなったら、ゲストアカウントでログインして dscl でパスワードのハッシュを読みだして、辞書とかレインボーテーブルとか総当たり攻撃をすれば、いつかは...

      親コメント
    • by Anonymous Coward

      えっw
      小さい問題でないどころか、こっちのほうが「ただちに」問題がおきるような。
      shadowのほうにしろ、こっちにしろ、普通に今まで通りにしておけば
      こうはならないわけで、わざわざこういう仕様にしたのか、ミスなのかなんなんだろう。

      • by Anonymous Coward

        枝野経産相「Macを知らない人に触らせなれければよいので、直ちに問題はありません。」

        • by Anonymous Coward

          枝野のその発言、日本語分からない人が誤読しまくってるので一応マジレスしておくけど、「ただちに問題は無い」=「少なくとも年単位で蓄積した後でなければ、短期的にも長期的にも影響は出ない」の意味だからね。
          Macは今すぐ問題。

          • by Anonymous Coward

            誤読では無いと思いますが
            前後の言葉も含めて、本人がそういった意味で使ったわけではないということだったのでは?

            単に「ただちに」には、そういった意味は無いみたいですが・・・

            • by Anonymous Coward

              「将来的にも影響は無い」と付け加えてるんだけどな。

  • by Anonymous Coward on 2011年09月20日 20時36分 (#2022273)

    またAppleが一つイノベーションを起こしてしまったか

  • by PEEK (27419) on 2011年09月21日 10時18分 (#2022475) 日記

    一般人がシャドーの情報にアクセスできるなんてストレイカー大佐も頭が痛いだろうな。

    --
    らじゃったのだ
    • by niwasa (4453) on 2011年09月21日 15時23分 (#2022623) ホームページ 日記
      ストレイカーは司令官だけど、階級は大佐なんでしたっけ? フォスターやレイクも大佐だよね。 ま、最専任士官ということか スカイ・ワンが発進した後のダイバーのほうはトリムが崩れて大変じゃないかと思う。 あと水中ノイズも盛大に出そうだ
      親コメント
  • by Anonymous Coward on 2011年09月20日 19時25分 (#2022222)

    > パスワードが直接閲覧できるわけではないが、ハッシュを読まれてしまうと総当たり攻撃などによってパスワードを解読されてしまう可能性がある。

    可能性を言い出したらキリが無いわけですが。

    • by kamisui (39000) on 2011年09月20日 19時44分 (#2022234)
      この場合、0%じゃなきゃ「可能性はある」よねって事ではなく、十分な現実的をもって「おそれがある」ということでしょう。

      そういうわけなので、対策の一つとしてゲストアカウントを無効にしておきましょう、というお話では。
      後は基本として短いパスワードは付けない。

      そのうち修正されると思いますが。
      親コメント
    • by Anonymous Coward on 2011年09月20日 19時47分 (#2022236)

      お安い GPU で強固なパスワードも用無しに [srad.jp]
      ハッシュが漏れた場合の総当たりはすでに十分現実的ですよ。

      親コメント
    • by Anonymous Coward on 2011年09月20日 23時04分 (#2022357)

      ツリーが無駄にのびているようだが、別に釣りではないので言いたかったことを少しまとめてみる。
      # というか、こういう洒落すら通じないほどハイレベルな場所になってしまったのか(汗。
      では、もう少し引用を短くしてみよう。

      >ハッシュを読まれてしまうと総当たり攻撃などによってパスワードを解

      ハッシュを読むこと、と、BFA (総当り)に、何の関係があるんだい?
      このケースのBFA に必要なのはハッシュではなく、ユーザ名であって、
      ハッシュによって少し楽になるのはDA (辞書攻撃)ではないかのな?

      もちろん、可能性を可能な限り排除する、という考え方には賛成するものだけれども、
      shadow 化によってBFA を完全に防げる、または、暗号化によって安全を確実に担保できるソリューションが
      もし、存在するのであれば、私の後学のために、是非とも教えて欲しい。

      また、断言するけれども、このダウングレードによってOSX のEAL [wikipedia.org]が取り消し、またはダウングレードする可能性は0 だろう。

      念のため繰り返すけれども、編集を弄っていたのであって、釣りではない。

      親コメント
      • ものすごく素朴な所からスタートすると、例えばこんなことが出来るというイメージ。

        1. たまたまログイン状態で席を離れた誰かのMacからその人のパスワードのハッシュを盗ってくる
        2. 家に帰って、自分のMacのパスワードテーブルのハッシュを、盗ってきたハッシュに書き換える
        3. ログインが成功するまでゆっくりのんびり総当たりでパスワードを試す
        4. 1の人のパスワードが分かる

        2022222 さんが勘違いをされてるとしたら、「総当たり攻撃」=「2~3の工程を被害者の人のMacで試す事」と思い込んでらっしゃる辺り。それは、時間はかかるわ怪しい痕跡は残るわだから、他の方法で防ぎようがある。

        そんなモロバレの間抜けな方法を使わず、↑みたいなバレにくい方法でも総当たり攻撃は可能なのでハッシュを盗られるのは危険。もちろん、↑も果てしなく間抜けなので、まともなプログラマならもうちょっとマシなパスワード解析方法を使う。わざわざログインを試さなくても、OSがパスワードとハッシュの一致を試す方法は広く知られてるので、その部分だけ繰り返し計算するプログラムを書けばよろしい。

        ので、タレコミ文の、

        >パスワードが直接閲覧できるわけではないが、ハッシュを読まれてしまうと総当たり攻撃などによってパスワードを解読されてしまう可能性がある。

        は、「パスワードそのものを盗られた場合と違って、その瞬間から悪用されるものではない」、「盗ったのが悪意と熱意のある人間であればいずれ何らかの攻撃を受けうる」、「弱いパスワードだと辞書攻撃でその『いずれ』が早まりうる」と、ツッコミ所も弄り所も特にない適切なまとめ。

        # なんか自分のidに似てたのでツッコミを禁じ得なかった。
        親コメント
      • 完全ではないにしても、たとえば5回ミスしたらロックとか、n回目以降はwaitが入るとか普通にあるんじゃない?
        で、パスワードをBFAするに現実的な時間で完了しないなら、それは解決策なんじゃないかな?

        あくまでアカウントリスト取得からBFAだけの視点で。

        で、ハッシュがとれるとですが、BFAするにして(つまりDAできないランダムで長いパスワードだったとして)もRainbowテーブルとの突き合せができるので、上記を回避しつつクラックすると。

        # たしかに皮肉というか洒落はあったと思うけど、要点は総当りより折角読めない位置にあるはずのshadow=ハッシュが素で読める点が重要だったから、重視されなかった、かなぁ?

        という感想をえたのですが、どんなもんでしょう?

        --
        M-FalconSky (暑いか寒い)
        親コメント
      • by Anonymous Coward

        >もちろん、可能性を可能な限り排除する、という考え方には賛成するものだけれども、
        >shadow 化によってBFA を完全に防げる、または、暗号化によって安全を確実に担保できるソリューションが
        >もし、存在するのであれば、私の後学のために、是非とも教えて欲しい。

        「完璧じゃないなら一切意味がない」なんてのは典型的な極論ですね。
        たいていは自分の過ちを認めないための逃げ口上です。

    • by Anonymous Coward
      shadowの意味が分からなくて解説して欲しいなら,素直に質問した方が良いですよ.
    • by Anonymous Coward

      攻撃者のローカル側で総当りを試せるので、認証失敗時のアカウントロック等で総当り攻撃を制限する方法の意味がなくなるといったところでしょうか。

      単純にハッシュの強度に依存することになるので、今後のプロセッサ技術の進歩により、セキュリティが弱くなる可能性がありそうです。

      • by Anonymous Coward
        今後といわず、最近流行のGPUを用いた辞書攻撃ですでに十分やばいでしょう
        shadowなんて取られたら分散処理でいくらでも並列化して辞書攻撃できますから
      • by Anonymous Coward

        ローカルで総当たり・・・つまりハードウェアを盗んでじっくりパスワードの解読が出来るってこと?
        まずローカルにアクセス出来るってことは・・・セキュリティ的にはあれだがw

        管理者権限でいつもログインしている自分は関係ないかwww

        • by Anonymous Coward on 2011年09月20日 21時57分 (#2022320)

          ハードウェア盗まなくても、Webアプリに穴があったり、PHPスクリプトやCGIを他者が設置できたりしたら、管理者権限なくとも、パスワードハッシュを取得されちゃう可能性があるということです(最悪リモートからも)。そして、取得されちゃったハッシュは「攻撃者のローカルなコンピュータ」で気の済むまで解析されちゃう可能性があるってことです。

          今だから白状するけど、昔NEXTSTEPのNetinfoシステムも、デフォルトの設定だとリモートからアクセスできて、パスワードハッシュが取れたことがありました。ファイヤーウォールがないと、スコーンとアクセスできちゃいました。で、クラックコードはしらせたら、短いパスワードは解析できちゃってビビッた覚えがあります。

          親コメント
          • by Anonymous Coward

            >Webアプリに穴があったり、PHPスクリプトやCGIを他者が設置できたりしたら、管理者権限なくとも、パスワードハッシュを取得されちゃう可能性がある

            そりゃそうだけどさ、大きな穴があいているのにわざわざハッシュを盗む奇特な人って・・・
            そんな馬鹿なWebアプリ作るような場合は、もっと大きな穴があるだろうと思うよ。

            まぁマルウェアなどと組み合わせて、多くのMacからハッシュを集めるようなことでも・・・そんなに大量のハッシュだと解析するのに時間がかかって意味ないかw

            • by Anonymous Coward

              >そりゃそうだけどさ、大きな穴があいているのにわざわざハッシュを盗む奇特な人って・・・
              >そんな馬鹿なWebアプリ作るような場合は、もっと大きな穴があるだろうと思うよ。

              そんな単純な話で済んだら、ネットセキュリティの世界は平和になるんだろうなあ。
              無知って本人だけは幸せでいいですよね。

              >まぁマルウェアなどと組み合わせて、多くのMacからハッシュを集めるようなことでも・・・
              >そんなに大量のハッシュだと解析するのに時間がかかって意味ないかw

              マルウェアで解析までさせちゃうんじゃないの?
              解析済みのパスワードをせっせと外部サーバに送信して、外部から侵入し

              • by s02222 (20350) on 2011年09月21日 10時46分 (#2022491)
                同じパスワードをあちこち使い回してる人が多そうなので、色々と応用が利きそうです。

                まあそこまで侵入できたら、ブラウザが覚えてるパスワードを狙った方が早そうだけど。
                親コメント
    • by Anonymous Coward

      ○ パスワードを解読されてしまう蓋然性が少なくない。

    • by Anonymous Coward

      もともと/etc/password ファイルには暗号化されたパスワードが格納されていて、そしてpasswdファイルは誰でも読めるようになっていました、というか今でもそうです。
      でもそれでは解析し放題だから、passwd ファイルにはダミーのパスワード'x'とでも入れておいて、一般ユーザには読めないshadowファイルに記録するようにしましょうというのが事の起こりだったと記憶しております。
      そもそもpasswdファイルを一般ユーザが読めないようにしなかったのは、そこからユーザ一覧を取得して処理するプログラムでもあったのでしょうか。
      なんか負の遺産ぽい気もしますが、次バージョンのMac OS Xではパスワードのハッシュを取得できる(rootにしか見えない)エントリが出来て今までのエントリにはダミーの値しか入らないようになったりして?

      • by espelette (42945) on 2011年09月20日 22時59分 (#2022355)

        /etc/passwd を読み込んで処理するプログラムはUNIXライクなシステムなら現役で
        多数存在しています。
        passwd という名前ながら、ユーザIDと
          * ユーザ名
          * プライマリグループ
          * ホームディレクトリ
          * ログインシェル
        といった情報とのマッピング情報を格納しているので、一般ユーザが /etc/passwd を
        読めなくなると、結構な数のプログラムがまともに動作しなくなります。

        ためしに chmod 600 /etc/passwd すると ls -l の出力のユーザ名や ps や top で
        表示されるはずのユーザ名が数字になってしまうのを確認できるはず。

        親コメント
    • by Anonymous Coward

      いろんなコメントがついているが。

      総当りで解かれるということは、既に逆引き辞書が作られているということだぞ。

      passwd見てから、おもむろに総当りで破ろうとするわけではないぞ。

      わかった上での議論と思うが、念のため。

      • 総当たり攻撃するだけなら、都度生成すれば済むんではないですか?
        どうせ、2^ハッシュのビット数文の都度生成で済むんだし。
        今時のCPUやGPUをつかったら、非実用的な時間でもないでしょう。

        勿論その前に、既に解明されてるハッシュの一覧辞書やよく使われるキーワードの組み合わせから作成したハッシュ辞書でパターンマッチングして、どれにも一致しないのだけ総当たりに掛けて潰せば良い。

        # で、とけたら、「既に解明されてるハッシュの一覧辞書」に追加(´ー`)y-~

        そして、その手の辞書はアングラワールドには掃いて捨てるほど流通してる。脆弱なキーワード一覧から、具体的な乱数パスワードまで。

        ハッシュの生成/認証構造がMac独自?ならば、認証機構関連をリバースエンジニアリングして、そこらに転がってるGNU/LinuxやWindowsで動くようなクローンやクラッキングユニットを作れば良い。
        所詮、相手がOTPとか外部のワンタイムトークンに依存してない以上、それはそう難しくない(それをやり慣れてる人にとっては)

        まぁ、CPUとかGPUの資源だけが欲しければ十万弱で相当高速な物が手にはいる時代だし、その手のソフト専用に機械を廻しても、得られる経済的対価が大きく勝るのならばやる奴は少なからずいる。
        (そして、自分でカード喰うにしてもゾンビマシンを作ってさらなる悪事の踏み台を作るにしても、ただ単純にそこらへんのマフィアに売っぱらうにしても、大きな経済的対価が見込める世界みたいですし)

        親コメント
      • by Anonymous Coward

        言いたいことが良くわからないが、総当りの範囲を辞書にしようとしても現実的じゃないサイズになる。TとかPとかEとか。だから総当りで試すわけ。
        辞書なんてのは極々々一部なんだけど、それで数割とかいうレベルで当たるから使われる。
        しかしそれから漏れてたらどうしようもないから、あとはおもむろに総当りしかない。

    • 最近なんだ、その、レベルが低いと言うより、ちょっとおもしろそうなたれこみをクリックしてコメント見ると
      がっくり来てしまうんだよな。
  • by Anonymous Coward on 2011年09月20日 19時58分 (#2022244)

    なんで、こんなことになったんだ?
    強化されるならともかく。

    • by Anonymous Coward
      10.x.0とか10.x.1とかなら、そんなもんだよ。
    • by Anonymous Coward

      LDAP で認証をやろうと思ったときになんだかすっごく面倒だった覚えがあります。
      NSS には渡すんだけど任意のユーザからは見えちゃいけないし、あれ、どうやるんだったっけ?
      まあそういうわけで、動くことを優先して安全を置き去りにするのはよくあることです。

    • by Anonymous Coward

      大半のMacユーザは別にshadowファイルのセキュリティなんて気にしないんじゃない?
      マシンのユーザ=マシンの所有者、ってのが普通で一般ユーザのクラックなんてあんまり気にしないのだと思う。

  • by Anonymous Coward on 2011年09月20日 20時40分 (#2022277)

    ユーザーがどのあたりを歓迎しているのかAppleとしてアンケートしてる状態なんじゃない?

  • by Anonymous Coward on 2011年09月20日 21時43分 (#2022312)

    情報セキュリティへの意識をユーザーに喚起させる。
    素晴らしい作戦だと思います。
    難点は、そのアプローチが失敗に終わることをWIndowsが証明していることです。

  • by Anonymous Coward on 2011年09月20日 21時49分 (#2022314)

    せっかくLionがらみでセキュリティ話が出たので、ついでに質問させてください。
    Lionをサーバとして運用する場合に、気をつけたほうがよいのはどのあたりでしょうか?
    #システム壊れても、すぐに現状復帰できるようTime Machine頼みでいいのかとか。なんでもよいので。
    開けるポートはWebとDB系の二つだけなのですが、
    そうすると、できることは、開けるポートを絞って、サービスに不具合が出ないよう祈りながら、
    できるだけバックアップとアップデートを繰り返すしかないような。
    プログラムに致命的なセキュリティホールがないことが前提ですが。。

    #Mac Miniってお値段も消費電力もお手頃で、個人で運用するサーバとしてはなかなか良いスペックだと思ったんですよね。
    #中身をLinuxやBSD系に入れ替えて運用している人が多いのかもしれませんが。

typodupeerror

弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家

読み込み中...