このブログを検索

ラベル セキュリティ の投稿を表示しています。 すべての投稿を表示
ラベル セキュリティ の投稿を表示しています。 すべての投稿を表示

2019/04/22

情報処理安全確保支援士試験(平成31年度春期)

情報処理安全確保支援士試験を受けた。

日曜日。

去年の秋にネットワークスペシャリストに受かったので午前1は免除。

会場は日大経済学部。水道橋にある。立派な校舎だ。しかも経済学部と書かれたビルがいくつもある。

早めに出かけたが、試験開始の1時間半も前についてしまう。

いくらなんでも早すぎだ。

校舎の前にベンチのようなものがあったのでそこに座ったが日陰で寒いので、ドトールに移動した。


30分くらい前に会場に入った。まだ午前1の試験が終わっていない時間だが、会場に人はまばらで試験は実施されていない。午前1免除の人たちだけの会場だったようだ。

情報処理技術者試験は何度か受けたが空席が多い。受験申し込みをしても当日来ない人が
けっこういるのだ。私も申し込んで受けなかったことが一度ある。

NWのときは3、4割くらいだったと思うが、今回は半分以上埋まっていた。けっこうな欠席率だが、情報処理技術者試験にしては出席率は良いほうだと感じた。午前1免除の人達だからということもあっただろう。

20分前に席に着くようにとの指示が受験票に書いてあるが、平然と10分前くらいに来る人がいる。

まったく悪びれる様子もない。試験官も特に注意することもない。

午後1のときは試験が始まってから入室してきたつわものがいた。やはり無表情であせりさえしていない。

午前2の1時間後に午後1が始まるのだが、20分前に着席しなければならないので、昼休みは40分しかない。

それはもうわかっていたので、コンビニでおにぎりを買っておいた。

肝心の試験の内容であるが、簡単だという印象。

午前2は全部解いて、正解だと確信できない問題が11問。

でも、見直しても多分これしかないだろう、という答え。

合格点は60点だから、10問間違えられる。

昔の情報処理試験は午前問の合格点は8割だったと記憶しているが...

確信できないといっても11問のうち半分まちがっているとしても余裕だ。

後で自己採点したら1個しか間違っていなかった。今までこんな高得点はとったことがない。



午後1は3問から2問選択。1問目によく知らないスクリプトのコードが書いてあったので、2・3問を選択。

2問目がやや不安だがなんせ合格点が6割だから。6割はとれてるだろうという感触はあった。

午後1を終えて、ここまではパスできているという自信があった。

あとは午後2。

2時間で2問中のどちらか1問を解く。

ざっと読んで、2問目が簡単そうだなと思ったが、最初の3つの穴埋めがわからない。

最初の穴埋めは簡単なはずなので、ここがわからないようではダメだ、と1問目を選ぶ。


構成やプロトコル等は自分が経験したことのあるものとそっくりで、何を言っているかわからないところもほとんどなく、すいすいと解答していった。

逆に、「こんな簡単な答えでいいのか?」と、不安になる。

1時間でとりあえず解き終える。

もうこのまま退席しても多分大丈夫、という感触だったが、一応見直す。

30分残して退席。


試験というものは大体、簡単だった、できた、絶対合格した、と感じたときはあまりできていないものなので、こういう記事を合格発表前に書くことはしないのだが、
今回はそれにしても、というくらい自信がある。


終わってからネットで検索したのだが、やはり、「SC(情報処理安全確保支援士)は簡単」、という人が散見される。


ネットワークスペシャリストに受かって、IPAの試験が大したことがないのがわかった。

昔より明らかに簡単になっている。合格点も低いし、合格率も高くなっている。

エンジニア不足を懸念してか、「落とす試験」から「受からせる試験」になっていると感じる。

さらに、安全確保支援士は合格後登録して有料の講習を受けるという特別な資格であり、合格者増はIPA(かどこだか知らないが)の収入増になるから、受験者はいいお客さんである。

NW、SCは高度な資格に区分されているが、今なら言えるが、CCNPの方が難しい。試験のタイプが違うので単純に比較はできないが、少なくとも必要な勉強時間はCCNPの方がはるかに多い。費用もかかるし。今は4万円くらいか?3つで12万円。それに加えてテキストとか、ping-tとか、実機を買ったりとか、そういうのもあるし。

一番大きいのはIPAの試験は過去問と解答、コメントまで公開されていることだ。NWもSCも、過去問を解く以外の対策はほとんどしていない。


....こんなことを書いて落ちてたら恥ずかしい。その時はこのエントリーを消そう。

(2019/6/21 追記)
受かった!
合格発表前に公開された午後2の解答例が全然自分が書いたものと違っていて不安になっていたが...
AM2:96, PM1:79, PM2:71 と、だいたい感触通りの結果。
午後問はやっぱり、かなりの部分点がもらえる模様。



2019/04/20

パスワードを平文で保存してはいけないならどうやって保存するのか?

あるサービスが「パスワードを平文で保存していた」というニュースに対してある有名な人が「平文で保存するなんてありえない!」と怒っていた。

「平文で保存していた」というニュースは何度か見たことがある。

では、平文で保存してはならないのならば、どうやって保存すればいいのか?

そう聞いたら、多くの人がこう答えるだろう。

「暗号化して保存する」

私もそうだと思っていた。

しかしそれは間違いで、正しくは

「パスワードのハッシュを保存する」

であった。


そういうとおそらく「暗号化もハッシュも同じようなものだ、そんな細かいことはどうでもいい」という人も多いだろう。

でも、そういう、「細かいことはどうでもいい」が積み重なって、「平文でも大丈夫」になってしまうのではないだろうか?

だから、ちょっと「細かいこと」にこだわってみよう。

ハッシュとか、暗号化とか、sha1とかmd5とかいうものの存在は知っていた。

ソフトウェアなどをダウンロードしたときにmd5チェックサムがついていて、
ファイルが壊れていないかを確認することができる、とか、

WEBサーバは、sha1は古いアルゴリズムだから、sha256を使わないといけないとか。


しかし、実際に自分がサーバ管理者やサービス提供者になったとして、
顧客のパスワードを安全に保存するにはどうすればいいかと聞かれたら答えられない。

最近、当たり前のことなのだが、知ってちょっと驚いたことがある。

それは、ハッシュというものは同じ値に対してはだれが計算しても同じ結果になる、
ということだ。


windowsのコマンドプロンプト(またはパワーシェル)で、
ハッシュを計算することができる。

別に何かのアプリなどをインストールする必要はない。

a.txt

というファイルがある。
中身は

あいうえお(改行)

で、文字コードをutf-8で保存した。


PS C:\users\taro\desktop> certutil -hashfile a.txt
SHA1 ハッシュ (対象 a.txt):
471399aeda50586bdc982b558bfde1da642c0fb3
CertUtil: -hashfile コマンドは正常に完了しました。

PS C:\users\taro\desktop> certutil -hashfile a.txt md5
MD5 ハッシュ (対象 a.txt):
0f2f3458c1553eb96d499508dc5184b4
CertUtil: -hashfile コマンドは正常に完了しました。

PS C:\users\taro\desktop> certutil -hashfile a.txt sha256
SHA256 ハッシュ (対象 a.txt):
0007a58ae5789f92155f87d6bc51edd4c9b036277d23154fe06a9daf33d0e514
CertUtil: -hashfile コマンドは正常に完了しました。


sha1(デフォルト)、md5、sha256で計算してみた。


それでは、このファイルを、私がさくらのVPSで使っているcentosのサーバにアップロードし、そこでハッシュを計算してみよう。

centosにもハッシュを計算するコマンドがある。

# sha1sum a.txt
471399aeda50586bdc982b558bfde1da642c0fb3  a.txt

# md5sum a.txt
0f2f3458c1553eb96d499508dc5184b4  a.txt

# sha256sum a.txt
0007a58ae5789f92155f87d6bc51edd4c9b036277d23154fe06a9daf33d0e514  a.txt


結果は全く同じである。

ハッシュというのは元の値に対して、人の目からは無意味である程度長く、元の値を推測も計算することもできないような値を生成する。

それはわかっていた。

しかしもうひとつ肝心なことは、同じアルゴリズム(sha1とかmd5とか)を使用すれば、
同じ値からは同じハッシュ値が生成されるということだ。

そうでなければ、たとえばユーザのパスワードのハッシュ値を保存しても、
ユーザのパスワードが正しいかを検証できない。

当たり前のことであるが。


私もパソコン、スマホ、さまざまなインターネット上のサービスなどを利用していて、
「パスワード」というものを何十個、何百個と設定して使用してきたが、
そのパスワードがテキストで読める状態で保存されているのは見たことがない。
パスワードをメールや郵便物に記載して送付されることはあったが。

あらためて、先ほどのcentosのサーバにパスワードがどのように保存されているかを見てみた。

/etc/shadow

というファイルである。

私は複数のアカウントを作成しているが、そのうちいくつかは異なるアカウントに同じパスワードを設定していた。

たとえば、taroというユーザのパスワードが password、
jiroというユーザのパスワードも password
という感じである。

「同じ値のhash値は誰が計算しても同じ」
ということは、taroとjiroのパスワードから計算したhash値は同じ文字列のはずだ......

しかし、実際には違う文字列であった。

あれ?


調べると、パスワードを保存する際にはhash値をもとの文字列からそのまま計算せず、
「ソルト(塩)」と呼ばれるランダムな値を付加して計算するのだそうだ。

その付加する方法は、文字列としてくっつけるのか、二進数でなんらかの演算をするのかわからないが、とにかくもうひと手間加えて、同じパスワードでも同じハッシュにならないようにする。


同じハッシュ値だからといっても、元の値を知ることは事実上不可能なことにはかわりないが、「複数のアカウントが同じパスワードである」という事実があれば、それらのアカウントに使用されているパスワードは誰もが思いつきそうな単純なパスワードであると推測できる。

また、よく使われそうなパスワード文字列を用意し、そのハッシュ値を計算しておいて、
ハッシュ値同士を比較すれば元の文字列がわかる。(これをレインボーテーブルという)

これらを防ぐために、ソルトというものが使われる。

しかし私はそこでひとつ疑問がわいた。

パスワードは正しい値であることを検証しなければならない。


再訪したユーザが入力したパスワード値にソルトを付加してハッシュ値を計算し、保存されたハッシュ値と同じであるかを比較しなければならない。

ではソルトをハッシュ値と一緒に保存するのか。
それは鍵をかけた金庫の横に鍵を置くようなものだ。

/etc/shadowを見てももちろんソルト値は書かれていない...

調べてみた。

ソルト値の隠し場所があった。

金庫のたとえで言うなら、鍵は金庫の横に置かれてこそいないが、
横にテープで貼り付けるくらいのことしかされていなかった。

ソルト値を使ってパスワードからhashを計算したら、
/etc/shadowに書かれているhash値と一致した。

# cat /etc/shadow | grep hiroshi
hiroshi:$6$9Qpwui9R$jrswaF/U2NRgq7Yhuk2YH7T2POuOYuDq/2eH71KMJkRDNaLxHEa25BLvmAnT3zz.ijxv/e6qUK.cEN24FN.GD0:18005:0:99999:7:::

# perl -e 'print crypt("hiroshidesu", "\$6\$9Qpwui9R");'
$6$9Qpwui9R$jrswaF/U2NRgq7Yhuk2YH7T2POuOYuDq/2eH71KMJkRDNaLxHEa25BLvmAnT3zz.ijxv/e6qUK.cEN24FN.GD0


pythonの例

# python -c 'import crypt; print(crypt.crypt("hiroshidesu", salt="$6$9Qpwui9R"))'
$6$9Qpwui9R$jrswaF/U2NRgq7Yhuk2YH7T2POuOYuDq/2eH71KMJkRDNaLxHEa25BLvmAnT3zz.ijxv/e6qUK.cEN24FN.GD0


そもそも、ハッシュ値で保存するのも、さらにその際にソルトを加えるのも、
サーバにアクセスされてかつサーバの管理アカウントでログインされてしまった場合を想定してのことである。

平文で保存していたのも、サーバにログインされないための対策を十分にしているから、
と考えてのことだろう。


sha512の計算方法とか、saltのかけ方とかはわからないが、
それを使ってますよ、というだけで、パスワードの保存方法というのはそんなに難しいことをしているわけではないというのが、分かった。

ただし、繰り返しになるが、それはあくまでも推測したパスワードからハッシュを計算して一致するかを調べる、ということであって、ハッシュ計算の脆弱性があるとか、ハッシュ値から元の値が算出できるとかいうことではない。


※関連エントリ

https://monqy.blogspot.com/2019/04/blog-post_27.html

2014/02/22

ディレクトリ・トラバーサル

ディレクトリ・トラバーサル という不正アクセスを受けた。
特に深刻な被害はないようだが、脆弱性があることがわかった。
一応対策した。


あまり詳しいことは書きたくないが、cgiでパラメータを受け取ってそれをファイルとして開いているのだが、
そのパラメータに "../../../../" を含んだファイル名を指定してその内容を表示させようとするのだ。
ミソは "../"である。ディレクトリをさかのぼって表示させるのだ。

こんなことができてしまうとは。