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

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

S2-046　struts2の脆弱性情報

https://struts.apache.org/docs/s2-046.html
S2-046

 

こんばんわ。

koutaです。

体調不良でやられていたので。。。

今日はこんな時間になりました。

 

新しい情報です。

脆弱性管理番号は　CVE-2017-5638　のまま変わりません。新しい攻撃方法が発見されたとの内容です。

 

また、パッチが発表されてます。

対応できるバージョンはReadmeに書いてあったので活用して下さい。

パッチを適用するにせよ、推奨は対応バージョンへのアップデートだそうです。

 

違う脆弱性が発見されたとか平気で書いてあるサイトいっぱいあったから気を付けてくださいね。

 

情報は発表元か信頼の置ける機関から入手しましょう☆

情報セキュリティ対策に足りないもの

こんばんわ！！

koutaです。

 

先日のstruts2の脆弱性のせいで(CVE-2017-5638,S2-045)仕事中にネットサーフィンすることが増えました。

 

そこてとある記事を見つけました。

情報セキュリティ対策に足りないものはなんと。

予算ではなく。。。

 

 

 

人材だそうです。

 

私は衝撃を受けてしまいました（笑）

 

 

イヤイヤイヤイヤイヤイヤ。。。。

と思わずつぶやいてしまいました。

 

 

まぁ都合の良い人材がいないということでしょうかね。

例えば、

======= パターン1 ============

改ざん検知、侵入検知をしたいからIPS/IDSを導入します。

ログ解析、パターン分析の技術者育成と機器購入や導入費用含めて1000万円(イニシャル900,ランニング100)です。

これによりセキュリティレベルで取れなかった20件の案件を取れるようになり、5年で回収できます。

============================

ではなく。

 ======= パターン2 ============

改ざん検知と侵入検知の仕組みを作るから100万円でやります。

(精度は自分の知識内になるから自信はないけど。。。)

十分対策できます！！

============================

という人材が足りないということでしょうか？

 

勝手な想像なのですけども。。。

いろいろ言う人はいるけど、我々に都合の良い人材はいないなーってとこですね。

 

私が思う一番足りないものは、

意思決定権のある上層部の

情報セキュリティに対する意識と知識です。

 

今回のstruts2の脆弱性も

悪意のあるリクエストを受け取った場合、任意のコードが実行可能です。という脆弱性。

これでなにが起こるかわからない人が多いです。

だから対策も遅れます。

 

漏れるのがメールアドレスと氏名くらいなシステムならまだしも。。。

住所やらクレジットカード番号やら保管してるシステムはすぐに対策できないならシステム停止を検討するレベルの脆弱性です。 

 

なんとかなって欲しいですよね。

 

正しいセキュリティ対策ができるようになると良いですね。 

Apache Struts 2 の脆弱性 (S2-045) に関する注意喚起

https://www.jpcert.or.jp/at/2017/at170009.html
Apache Struts 2 の脆弱性 (S2-045) に関する注意喚起

 

最新情報です。

struts2をアップデートできない場合の対策と言われていた。

パーサーの変更ですが、

それでも攻撃されることが確認されたそうです。

 

そっちで対策してたらショックですね。

昨日ですが、試しに自分の環境でやってみたら簡単にサーバーコマンド実施できました。

 

やりたい放題できる感じでしたよ。

 

脆弱性っていろいろ出てるけどなんか危機感ないことが多いですよね。

 

今回は世間で騒がれてるから、みんな騒いでる感じですよね。

 

おいらはあっという間に準備してくださいって言ったけどね。。。

まぁ下っ端が言ってもみんな動かないけど。。。

さて対策頑張りましょう。

2017年3月に発生したApache Struts 2で稼働していたとみられるWebサイトへの不正アクセスについてまとめてみた - piyolog

http://d.hatena.ne.jp/Kango/touch/20170311/1489253880
2017年3月に発生したApache Struts 2で稼働していたとみられるWebサイトへの不正アクセスについてまとめてみた - piyolog

 

展開しておきます。

被害をまとめているサイトです。

 

どこの会社も同じだと思いますが、

サービス停止を伴うバージョンアップには反対するとこが多いです。

 

自社の利益のほうが大切ですから。

G社の67万件全てに500円(よくある数字)を補填したとしたら、3億3500万円の損失ですね。

 

サービス停止の損失よりは大きいと思うのです。

こういう判断ができる人がいないのよね。

 

struts2の脆弱性が発表されたタイミングで、

  1. 委員会設置
  2. リスク棚卸
  3. 対応検討

までやった会社があれば転職したいくらいです（笑）

 

テスト自動化が出来ているところでは、

冗長化してなくても、短期間のシステム停止対応できると思いますが。。。

 

現実はそうはいかないですよね。

 

サイバー攻撃から完全に守ることは、もう無理だと思うので。

漏れても被害が無いような環境構築がベストだと思います。(理想論で申し訳ありません)

 

ちなみにですが、

struts1には該当のコードがないとのことで今回の脆弱性には関係ないとのことです。

 

とはいってもサポート終了しているのて、

脆弱性やバグが内包されていても調査すらされないので気をつけましょう。

Apache Struts 2における脆弱性 (S2-045、CVE-2017-5638)の被害拡大について | LAC WATCH | 株式会社ラック


Apache Struts 2における脆弱性 (S2-045、CVE-2017-5638)の被害拡大について | LAC WATCH | 株式会社ラック

 

ラック社の記事ですが、リンクを貼ります。

先日紹介したstruts2の脆弱性問題ですが、

かなりの広がりを見せています。

 

実際に情報流出の被害も出ております。

 

扱ってる情報にもよるとは思いますが、

ネットワークから隔離も考慮した方がいいとのことです。

 

ひとまず共有します。

 

記事にも書いてありますが、

条件によっては侵入を検知できないので、

注意深く見守りましょう。

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. ストレッチングする(複数回やる)

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