情報処理　セキュリティブログ

情報処理系の話、セキュリティの話など書いていきます。

Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)：IPA 独立行政法人 情報処理推進機構


Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)：IPA 独立行政法人 情報処理推進機構

 

出ていたので共有します。

お陰様で大変。。。(´Д⊂ヽ

じゃなくて。

 

注意してください。

 

今回はstruts2というwebアプリのデファクトスタンダードともいうフレームワークでの脆弱性です。

 

ネットで調べると。。。

攻撃コードが出てきます。

 

あるツールがあればやりたい放題できます。

 

(世間に)一言言っておきたいのですが。。。

脆弱性を見つけたとしてもコードを公開みたいなことはやめてほしいのです。

脆弱性を扱う組織に通報だったり、

ホワイトハッカーとして開発会社やら組織への通報だったり、報奨金交渉だったりしたら良いのです。

 

ソースコードややり方を公開するのは、悪意のある攻撃を増やすための行為でしかありません。

 

愉快犯にはならずに、然るべき対処をして然るべき報酬をもらいましょう。

正しいハッシュ化

こんばんわ！！

koutaです！！

 

本日は正しいハッシュ化についてです。

 

その前に。。。

SHA1のアルゴリズムについてですが、

衝突が見つかったようです。

論理的には昔からあると言われていましたが。。。

https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html?m=1

 

衝突というのは、違う値でもハッシュ化後の値が一致してしまうことです。

 

なんかネットで見てると

膨大な施行が必要なので差し迫った対応は必要ない。

的な記事もありました。

 

確かに。。。

9,223,372,036,854,775,808回(いくつやねん)

の試行が必要で、

第一フェーズには6500年のCPU計算

第二フェーズには110年のGPU計算

だそうな。

英語が苦手な私は、

CPU何個でやねん。

と突っ込んでしまいそうです。

誤訳しているかもしれませんが。。。

30日後にはコードと共に公開するそうです。

 

公開されてしまうので差し迫った対応をしましょう！！

 

先日、SHA2のアルゴリズムも危ないということを書きました。

ハッシュ化　＋　ソルト

という話ですが

もう一つ追加してほしいのが、

ストレッチング

です。

 

ハッシュ化した値とソルトをまたハッシュ化してほしいのです。

何度もストレッチングを繰り返すことでハッシュ化を重ねます。

 

なのでハッシュ化したい場合下記のようにするとよいです。

(わかりにくい数式でごめんなさい)

 

1.ハッシュ化文字列＝ハッシュ関数(対象文字列　＋　ソルト)
2.ストレッチング文字列＝ハッシュ関数(ハッシュ化文字列　＋　ソルト)
3.ストレッチング文字列＝ハッシュ関数(ストレッチング文字列　＋　ソルト)

 

以降ストレッチングの繰り返し。

数百から数万の繰り返しが良いみたいです。

 

何故こんなことをするかというと。

 

脆弱対策をしても、どれだけ気をつけても、流出するときは流出します。

 

仮に、私みたいな立場の人間が悪意を持ってやったらうちの会社の情報は簡単に出せます。(やりませんが)

 

流出は前提として。

流出した場合に被害に合う前に対策をうつ時間稼ぎの為です。

 

ちなみにストレッチングのいいところは独自の暗号化アルゴリズムを考えなくて良いところです。

 

ハッシュ前の文字列とソルトが流出したところで、

ストレッチングの回数まで合致しないとハッシュ値が合致しないので十分対策時間が取れると思います。

 

先程のgoogleの記事にMD5のアルゴリズムは1つのスマホで30秒で解析可能と書いてありました。

頭の固いおっさんがいたら突きつけてやってください。

 

情報流出した場合のコストはハッシュ化アルゴリズムを変えるコストに比べたら微々たるものですよと。

具体的数値を突きつけて説明してやってください。

1万人流出したとして、500円補填したら500万円の損失で。。。

評判が下がるとこによる副次的効果を入れたら。。。

対策したほうが良いに決まってます。

 

お金が絡むと状況によりますけど。

 

ということで、

ブログを読んだ皆さんは、

  1. ハッシュ化はSHA256より強いもの
  2. ソルトを使う
  3. ストレッチングする(複数回やる)

ということでお願いします。

パスワードの保管方法

こんばんわ！！

koutaです。

 

日が開いてしまいました。

本来であれば、情報の棚卸のフォーマットを作って説明の予定でしたが、

作るってる時間がとれなくて。

別テーマにしてしまいました！！

 

ごめんなさい(´Д⊂ヽ

 

本日はパスワードの保管方法についてです。

端末の話ではなく、webアプリの話です。

 

皆さんはどのようにパスワードを保管してますか？

  1. 平文
  2. 暗号化
  3. ハッシュ化

 

どれが正しいでしょうか？

 

 

 

こんな風に並べたら3.ハッシュ化を選ぶと思いますが、

ハッシュ化だけでは不十分です。

 

平文で保管しているのは良くないです。

イントラでない限りはやめましょう。

 

暗号化とハッシュ化の違いはわかりますか？

 

暗号化は可逆です。

復号化することでもとに戻せてしまいます。

 

 

ハッシュ化は不可逆です。

もとの値を作るのは困難です。

 

困難なだけで、可能なのです。

例えばMD5というハッシュ関数。

http://www.kiyori.co.jp/md5reverse/

なんと分かってしまいます。

 

MD5,SHA1については既に脆弱と言われています。

SHA2でも実は結構危ないのです。

 

最近スタンダードやSHA256のハッシュ関数ですが、

技術が発達しすぎて、

200万円くらいの端末で、1億パターン/秒のスピードで解析できるらしいです。

 

8桁の数字と分かっていたら

たった1秒でパスワードが解析されるということです。

 

 

IPAで推奨されているやり方は

パスワード　＋　ソルト

のハッシュ化です。

 

ソルト(SALT)とは、任意の文字列です。

パスワードを解析するのを困難にするためのものです。

 

個人的には下記の条件が満たせると良いです。

  • 20文字以上
  • ユーザーごと異なる

 

 少し長くなってしまったので今日はここまてでです。

次は具体的なハッシュ化の仕方を書きます。

 

ではでは。

 

WordPress の脆弱性対策について：IPA 独立行政法人 情報処理推進機構

おはようございます。

koutaです。

 

こんなん出てました。

大至急だそうです。

WordPress使ってる方は至急アップデートしてください。

 

投稿内容の改ざんが可能だそうです。


WordPress の脆弱性対策について：IPA 独立行政法人 情報処理推進機構

 

少し内容の説明だけ。。。

REST APIの脆弱性だそうです。

 

悪意のあるリクエストで。。。とのことです。

WordPressの様なコンシューマ向けのシステムでAPIを作ったらシステム的な不具合が発生しない程度になんでもリクエストを受け入れなきゃいけないでしょうね。

 

設計には参加したくないですね（笑）

 

こんなこと言ってはいけませんが。。。

正直、1つくらい脆弱性のある処理が出ても不思議じゃないと思います。

 

脆弱性って診断も判定も難しいんです。

わかりやすいのはわかりやすいのですが。。。

 

脆弱性あるけど、重大なリスクを受容するという判断も実際にはあるので。

サポートの切れたOSやブラウザつかってるとかですね。

 

テストとか大変だと思いますが、改ざんされてから起こる事件に比べたらコストは低いはずなので頑張ってください。

情報セキュリティの制度

こんばんわ！！

koutaです。

 

前回は教育について少し書きました。

まとめるとちゃんと意識出来るように教育しなさいって話でした。

 

今回は制度についてですが。

まともに書いたらどうなってしまうのか…という感じなので。

詳しくは個別に書いていくとして概要でいこうと思います。

 

制度の目的は

  1. 情報流出のリスクを減らす
  2. 情報を適切に扱うことが出来る
  3. 利便性を極力そこなわない。
  4. 守らせる！！

です。

 

情報セキュリティの3大要素というのがあり。

  • 機密性(認可された人だけがアクセスできるようにすること)
  • 完全性(正確な情報であること)
  • 可用性(使いたい時に使えること)

最近はさらに3要素追加されていて。

  • 責任追跡性(いつだれが何をしたかを追跡できる)
  • 真正性(なりすましや虚偽の情報でないこと)
  • 信頼性(矛盾がないこと)

ということが出来るように制度化していきます。

大切なことは一気にやろうとしないこと。

ゆっくり組織に浸透させていく事が大切です。

(責任者の任命とかは抜いてます)

1.扱う情報の棚卸

　現状の把握です。

2.情報のレベルの決定

　個人情報ありとか、社外秘とかね。

3.社内のフロアを情報のレベルにより分割(ゾーニング)

　個人情報はこのエリアのみ等。

4.情報の管理台帳の作成

　誰か何をどのようにがわかるもの

5.罰則規定の決定

　性善説に立つとすぐに情報漏洩します。

 

簡単に書くとこんな感じかな？

ただ上記を素直にやってしまうと。。。

すぐに不満だらけになります。

 

セキュリティを強くすると利便性がそこなわれるからです。

実際は組織を上手く組み合わせていろんな部分を簡略化していくことになります。

(多分皆さんの組織でもそうなってます)

 

今日はこの辺にしておきます。

情報セキュリティの3大要素と追加の3要素が原則ということを覚えておきましょう☆

 

セキュリティ意識2

こんばんわ！！

koutaです。

 

装飾が微妙ですが、スマホだと書くのはそれほど大変じゃないですね。

パソコンは起動するという障壁がありますから（笑）

 

さて。

昨日の質問の答えはわかりましたか？

 

問：公共交通機関などで、社内情報を話してしまうような人達はどうやってやめてもらうのか？

 

答：教育と制度

 

制度についてはだいぶ長くなるので

今日は、教育について。

 

情報セキュリティ教育をしましょうということです。

制度がちゃんとしていれば、どのように社員に守らせるか？というところです。

 

まず情報漏洩の危険性について教育が必要です。

個人情報が漏れて1人500円の保障をしたとします。

漏れた人数が10万人でした。

500✕10万でなんと。。。5000万のコスト。

会社の損失はそんなもんですが、漏らした本人は降格したり、謹慎になったり、大変なもんです。

 

どんなことが起こるかを具体的に教える事が大切です。

 

そして継続的な教育が必要です。

 

意識として扱っている情報の重要性を認識し、漏洩経路がわかるようになれば万々歳です。

 

意識がちゃんとしていれば、

この間のM省はメールを送る際に暗号化していたわけです。

制度がちゃんとしていれば、メールは送信しなかったかもです。

 

教育で守らせて制度で防ぐイメージです。

 

 

 

 

ちなみにですが、

今年の5月30日に何があるか知ってますか？

 

知らない人はニュースをみましょう！！

会社から教えられてない人はちゃんと教育してくださいと、法務や人事に訴えましょう。

 

 

2017年5月30日は個人情報保護法の2015年改正分が施行されます。

 

内容は。。。

自分で調べましょう（笑）

 

こんな風に最新の情報を扱うことも大切です。

セキュリティ意識

こんばんわ。koutaです。

昨日は前職の同僚と飲みに行ってました。

おかげ様で今日はしんどい一日でした。

今日はスマホなので難しい内容は大変なので。。。

IoTの続きではなくセキュリティのお話を。。

 

さて、通勤や出張で公共交通機関に乗ることがあります。

 

社外秘の情報を読んでる人をとか、

クライアントとメールをしてる人とか、

どっかの不動産屋は普通に登記の書類を電車で読んでたました。

 

気持ちはわからないでもないのですが、

完全にアウトですね。

 

こういうことをされないようにどうしたら良いのでしょうか？

情報セキュリティスペシャリストの試験でも出るような内容ですが。。。

 

さてさて。

考えてみてください。

次の記事で答えを書きます。

 

でわっ！！